v1 아키텍쳐 (3계층 아키텍쳐)
- 우선 v1 아키텍쳐에 대해 돌아보자
- 3계층 아키텍쳐
계층형 아키텍쳐란?
- 각 계층별로 역할을 분리함
- 상위계층은 하위계층 의존할수 있지만, 하위계층은 상위계층을 의존하지 못한다.
문제점
- service에서 모든 로직을 절차지향적으로 처리하는 슈퍼 함수를 작성하게됨
- 코드 작성후 몇개월이 지나 로직흐름을 이해하기가 힘들었음 (특히 대회 신청, 결제 로직 수정이 너무 두려웠음)
v2 아키텍쳐
1. Domain Layer 도입 (domain model pattern 적용)
- 도메인 레이어로 도메인 로직을 분리
- ApplicationService 는 DomainService, DomainEntity, Repository 를 조합해서 비지니스 로직을 수행
- DomainEntity
- 도메인 모델의 데이터를 포함하며 해당 데이터에대한 처리와 관련된 기능을 제공
- DomainService
- 외부 시스템 연동이 필요한 도메인 로직
2. Domain Layer 와 infrastructure Layer 간 의존성 역전의 필요성
위에 아키텍쳐에서는 DomainService 가 Repository를 의존하고 있다.
만약 orm 이 typeorm 에서 prisma 로 변경된다면, AppService, DomainService 에서 repository 코드들을 모두 수정해주어야한다.
외부 기술의 변화가 도메인 계층 코드 수정을 일으키게되는 문제가 생긴다.
클린아키텍쳐, 헥사고날 아키텍쳐에서는 DIP(의존성 역전)을 통해서 위 문제를 해결한다.
코드예시
- IUserRepo를 인터페이스를 두고 UserRepo가 IUserRepo에 의존하게 함으로써 의존성을 역전한다.
3. 아키텍쳐 결론
- 결론
1. Domain Layer 도입- 적용2. Domain Layer 와 infrastructure Layer 간 의존성 역전의 필요성- 적용 안함- entity 로 타입 통일 (기본적으로 이렇게 하면 안되고, 계층간 낮은 결합을 위해 dto 를 활용하여 모두 분리해야 함)
- 결정이유
- 어차피 typeorm 으로 구현할거라 orm 변경의 여지가 적음.
- 추상화하는것도 비용이기때문에 각 팀의 요구사항 과 비용(돈, 시간)에 따라 적용할지 말지 고민하는것이 중요
4. 더 알아볼 내용
- 클린, 핵사고날 아키텍쳐: 위에서 설명한것보다 복잡하고 구체적인 규칙들이 존재
- CQRS: 읽기와 쓰기를 분리하자
- 이벤트 : 도메인간 메시징을 이벤트로 처리함으로써 메시징 결합도를 낮추자