갑자기 PHP를 이야기합니다;
옛날옛날에 PHP가 있었습니다. 그리고 그 시절을 그리워하는 사람들이 있답니다.
Think about how webapps are created with PHP. You create some files, write PHP code, then simply deploy it. We don't have to worry about routing much, and the app is rendered on the server by default.
That's exactly what we do with Next.js. Instead of PHP.
그렇습니다. 정말로 이렇게 적혀 있답니다;
저는 여기서 특히 routing을 이야기하고 싶고, "After that, the file-system is the main API. Every .js file becomes a route that gets automatically processed and rendered." 라는 말을 의식하면서, 저 또한 이번에 Spring Boot로 REST API를 만들어 보았습니다. 그리고 프로젝트가 끝나고 이렇게 한 번 정리해보고 싶었어요.
application.yaml
갑자기; yaml의 MyBatis 설정부터 보겠습니다
mybatis:
type-aliases-package: com.ooxo.api.*.type
mapper-locations: classpath:mapper/*.xml
type-handlers-package: com.ooxo.api.common.type느낌이 오시나요?
헷.. 그렇습니다. 디렉토리를 아키텍쳐 레이어가 아니라 비즈니스로 구분했습니다.
그래서 각 비즈니스별로 타입이 있기 때문에 type-aliases-package의 끝이 아니라 중간에 *가 있고요,
그럼 나머지는 자연스럽게 상상이 되실거에요
이런 느낌이에요
/com.ooxo.api
ApiApplication.java
/business1
B1Controller.java
B1Mapper.java
/type
AType.java
BType.java
...
/business2
...
/business3
...
...
/common
MyAdvice.java
...
/type
MyTypeHandler.java
ZType.java
...
/resources
application.yaml
/mapper
B1Mapper.xml
...하여, 각 컨트롤러의 라우팅은 해당 디렉토리명=비즈니스명을 참고하는거죠
@RestController
@RequestMapping("/business1")
public class B1Controller@ControllerAdvice나 @Configuration등은 common에 넣고요
비즈니스 구조를 의식한 API 만들기
그쵸, 제가 진짜 하고 싶었던 것은 비즈니스 구조를 의식한 API 만들기 였답니다.
비즈니스는 언제나 복잡하지만, 비즈니스 또한 사람이 하는 일인 이상
어느정도의 구분은 분명 있을거라고 생각해요.
그걸 그대로 API에 녹이고 싶었습니다.
비즈니스는 RESTful한 URI로 표현할 수 있고,
이걸 그대로 디렉토리 구조까지 가져가고 싶었습니다.
여기까지 오셨다면
우아한 모노리스 슬라이드의 34쪽 '도메인 중심으로 응집도 높은 모듈 구성하기'를 한 번 읽어주세요!
고민
규모가 작은 프로젝트였기 때문에 가능했던걸까요?
