한 달의 과정
이론 학습 기간이 끝나고 토이 프로젝트를 시작하는 단계가 진행되면서 실무에서는 생각하지 못 했던 부분들을 고민하게 되었다.
gradle로 멀티 모듈을 구성하는 방법부터 모듈간 의존성은 어떻게 관리할지, 소프트웨어 아키텍처의 여러 가지 방법에 대한 장,단점을 이해하고 최선의 선택은 무엇일지 처음으로 고민해보게 된 것 같다.
- gradle 멀티 모듈 구성 방법과 기준
- 레이어드 아키텍처와 헥사고날 아키텍처의 장,단점
- 만들면서 배우는 클린 아키텍처 후기
- 지속 성장 가능한 소프트웨어를 만들어가는 방법
- 도메인과 인프라간 경계를 명확히하여 순수한 도메인 영역을 만드는 것이 핵심이지 않을까? 자연스럽게 영속성 프레임워크의 기능에 의존하는 것도 떨어지게 된다는 점도 특징이다.
- 이 두 아키텍처 중 정답은 없다. 현상황에 대해 이해하고 두 아키텍처를 적절히 혼용하여 단점을 희석시키고 장점을 부각시킬 수 있는 방법을 찾는 것이 정답이다.
- 좋은 설계를 만족시키기 위해선 ORM과 작별 인사를 해야 한다, 도메인 모듈 분리 시 Transaction + JPA 활용 방안
- 파사드나 애그리게이트가 서로 다른 문제를 해결하는 것인가?
- 누군가는 비즈니스의 복잡도를 안고 중개하는 역할을 해야 한다. 그런 관점에서 보면 파사드와 애그리게이트는 서로 같은 문제를 해결하는 것이다.
- 복잡도를 누구에게 전가하여 중개를 어느 계층에서 어떤 방법으로 복잡도를 관리할지 스스로 어떤 규칙을 정하고 지키는 것이 핵심 아닐까
- rest docs 적용
느낀점
실무에서 레이어간 의존성에 대한 고민만 해왔지 멀티 모듈을 사용한 의존성에 대한 고려는 엄청 새로웠다. MSA를 대비한 도메인간 멀티모듈을 적용하는 것과 모놀리식 환경에서 레이어간 멀티모듈을 적용하여 각 모듈이 의존하는 의존성을 완전히 분리하여 서로 침범할 수 없도록 강제하는 것들을 배울 수 있었다.
소프트웨어 아키텍처와 비즈니스 로직 복잡도에 대한 내용들은 구조(또는 방법)을 선택하였을 때 얻는 것과 잃는 것은 무엇인가? 당위성을 설명할 수 있는가?를 생각하게 되는 주제들이였다.
내가 해결해야 할 문제가 무엇인지 이해하지 못하고 특정 기술적인 단어에 집착하여 단편적인 문제 해결 방법들만 고려했던 것은 아닐까?
문제를 해결하기 위한 정형화된 방법을 찾는것이 아니라 현재 환경에서 맞닥뜨린 문제를 이해하고 발전시킬 부분과 포기할 부분을 신중히 선택해야한다.
이번 학습을 통해 토이 프로젝트에 대해 어떤 아키텍처를 사용하게 되었는지 소프트웨어 아키텍처에 대한 고민도 작성하게 되었다.