2. DDD Layered Architecture
비즈니스 도메인을 중심으로 서비스를 모델링 하여 개발하고, 계층을 나누어 관심사를 분리하여 유지 관리를 효율적으로 하기 위해 DDD Layered Architecture를 적용했습니다.
- 요청을 전달받고 요청을 수행하기 위해 작업을 하위 계층에 위임
- 응답 전달
~Controller, ~Dto
- 하나의 요구사항을 수행하기 위해 필요한 작은 단위의 작업들을 정의하고 하위 계층에 작업 위임
- 트랜잭션으로 묶여야 하는 도메인 로직이나 트랜잭션으로 묶일 필요는 없지만 애그리게이션이 필요한 로직 정의
~Facade
facade는 복잡한 여러 개의 코드 집합을 하나의 인터페이스로 애그리게이션하는 역할입니다. application layer의 facade는 하나의 요구사항이 포함하는 작은 단위의 작업들을 애그리게이션 하고 각각의 작업들로 들어갈 수 있는 인터페이스 역할을 하고 있습니다. 하나의 요구사항을 수행하기 위해 필요한 작업들의 조합을 정의한 클래스이며, interfaces layer에서는 facade에 정의된 각각의 작업들은 신경 쓰지 않고 하나의 요구사항 수행을 위한 데이터만 전달합니다. 예를 들어서 자동 입찰 요청이 전달됐을 때 facade에는 다음과 같은 작업들이 정의될 수 있습니다. 실제로 작업을 처리하기 위한 로직은 domain layer에 작성합니다.
- 자동 입찰 요청 처리(기존 자동 입찰이 종료되고 새로운 자동 입찰을 관리)를 위한 메서드 호출
- 기존 자동 입찰자에게 자동 입찰 종료 알림 전송을 위한 메서드 호출
요구사항에 따라서 facade에 정의되는 작은 단위의 작업이 단 한 개만 존재할 수도 있습니다. 애그리게이션이 필요하지 않은 요구사항이어도 interfaces layer에서 domain layer로 바로 이동하지 않고 application layer를 항상 통과하도록 개발하고 있습니다. 향후 추가될 수 있는 작업에 대응하고 본래의 구조를 유지하고자 했기 때문입니다.
- 도메인 정의
- 비즈니스 로직 작성
Entity(Auction, User 등), ~Service, ~ServiceImpl, ~Reader, ~Store, ~Command, ~Info
reader, store는 데이터 읽기, 쓰기를 담당합니다. infrastructure layer의 기능을 직접 사용하지 않기 위해서 domain layer에서는 interface로 추상화하고 infrastructure layer에서 구현합니다.
command는 요청 처리에 사용할 데이터를 하위 계층에 전달하는 역할을 담당합니다. interfaces layer에서 dto가 command로 변환됩니다.
info는 응답을 상위 계층에 전달하는 역할을 담당합니다. info는 interfaces layer에서 dto로 변환됩니다.
- 상위 계층의 작업을 지원하는 기술적 기능 제공
- 도메인 영속화, 메시지 전송 등
~Repository, ~ReaderImpl, ~StoreImpl
application과 infrastructure는 domain을 바라보게 하고 양방향 참조는 허용하지 않습니다. 그리고 domain은 low level 기술에 상관없이 독립적으로 존재할 수 있어야 합니다. low level 기술에 의존하게 되면 구현체 교체, 테스트 등이 어려워질 수 있기 때문입니다. domain에서 infrastructure의 low level 기술을 직접 사용하지 않고 domain에 inferface를 생성하고 infrastructure에서 구현하도록 해서 infrastructure에 대한 의존을 최소화합니다. runtime 시 의존관계 역전 원칙(Dependency Inversion Principle, DIP)이 적용되어 구현을 추상화한 interface에 의존하게 하는 것입니다.
