[DDD Start!] 2. 아키텍쳐 개요

아키텍쳐

1. 표현 ( = UI 영역)

• 사용자의 요청을 받아 응용 영역에 전달하고, 처리 결과를 다시 사용자에게 보여주는 역할
• ex. 웹 어플리케션
  • 스프링 MVC 프레임워크
  • 표현 영역의 사용자는 웹브라우저를 사용하는 사람 or REST API를 호출하는 외부 시스템
• 컨트롤러 레이어

2. 응용

• 시스템이 사용자에게 제공해야할 기능을 구현 - 도메인 영역의 도메인 모델을 사용
• 로직을 직접 수행하기보다는 도메인 모델에 로직 수행을 위임
• 서비스 레이어

3. 도메인

• 도메인 모델(엔티티와 밸류)을 구현
  • 도메인의 핵심 로직을 도메인 모델에 구현

4. 인프라 스트럭쳐

• 구현 기술에 대한 것을 다룸.
• ex. DB 연동 처리, 메시징 큐 전송/수신 기능, SMTP를 이용한 메일 발송 기능

---

• 도메인의 복잡도에 따라 응용/도메인 계층을 합치기도 함.
• 계층 구조를 엄격하게 적용하면 상위 계층은 바로 아래 계층에만 의존을 가져야하지만 구현의 편리함을 위해 계층 구조를 유연하게 적용한다. (응용 계층이 인프라스트럭쳐 계층에 의존)
• 표현/응용/도메인 계층은 상세 구현 기술을 다루는 인프라 스트럭쳐 계층에 종속되게 됨.
  • 문제 1) 상위 레이어만 테스트 하기 어려워짐. (테스트 어려움) 인프라 스트럭쳐가 정확히 동작해야 완벽하게 동작하므로.
  • 문제 2) 구현 방식을 변경하기 어려워짐 (기능확장의 어려움) 기존 인프라 스트럭쳐에 특화된 코드가 상위 레이어에 작성될 수 있음
  ⇒ 해결 : DIP 적용

DIP (Dependency Inversion Principle; 의존 역전 법칙)

• 고수준 모듈: 의미 있는 단일 기능을 제공하는 모듈 저수준 모듈: 하위 기능을 실제로 구현한 것 ⇒ DIP는 저수준 모듈이 고수준 모듈에 의존하도록 바꾼다. 인터페이스를 사용
• 서비스 레이어에서 사용해야하는 구현부를 인터페이스로 먼저 정의하고 → 구현 클래스는 인터페이스를 상속받아서 필요 기능을 구현한다.
• 실제 사용할 구현 객체는 의존 주입을 이용해서 전달받음 구현 기술을 변경해야할 경우에도 의존성 주입 부분만 변경해주면 됨.
• 테스트 시에도 대용 객체를 사용해서 테스트를 진행할 수 있음
  • ex. stubRepo, stubRule을 Mockito Mock 프레임워크를 이요해서 대용 객체로 생성할 수 있음

*하위 기능을 추상화한 인터페이스는 고수준 모듈 관점에서 도출해야하며, 고수준 모듈에 위치한다. → 저수준 모듈에서 인터페이를 추출하면 안된다. (단순히 인터페이스와 구현클래스를 분리하는 개념이 아닌, 고수준 모듈이 저수준 모듈에 의존하지 않도록 하기 위함임)

---

• 아키텍쳐 수준에서 DIP 를 적용하면 인프라 스트럭쳐 영역이 응용/도메인 영역에 의존하는 구조가 된다.
• DIP를 적용하면 상위 영역에 영향을 최소화하면서 구현체를 변경하거나 추가할 수 있음
• 하지만 무조건 인프라 스트럭처에 대한 의존을 없애는 것이 좋은 것은 아님
  • ex. 스프링 트랜잭션 처리르 위해 @Transactional 사용 or JPA 전용 어노테이션을 도메인 모델클래스에 사용하는 경우(@Entity, @Table) → 구현의 편리함은 DIP의 장점만큼 중요하므로 유연하게 적용해야함.

도메인 영역의 주요 구성요소

1. Entity 엔티티

• 고유의 식별자를 갖는 객체
• 자신의 라이프 사이클을 가짐
• 도메인의 고유한 개념을 표현 (도메인 모델의 데이터 + 데이터 관련 기능)

2. Value 밸류

• 고유의 식별자를 갖지 않는 객체
• 개념적으로 하나인 도메인 객체의 속성을 표현
• 엔티티의 속성 or 다른 밸류 타입의 속성으로 사용

3. Aggregate 애그리거트

• 관련 객체(엔티티, 밸류 객체)를 개념적으로 하나로 묶은 것
• ex. '주문' 애그리 거트 = Order 엔티티 + OrderLine 밸류 + Order 밸류 객체
• 도메인이 커질수록 개발할 도메인 모델도 커지면서 많은 엔티티와 밸류가 출현 → 복잡도 높아짐. → 애그리거트를 사용하면 관련 객체를 묶어서 객체 군집 단위로 모델을 바라볼 수 있게 됨
• 군집에 속한 객체들을 관리하는 루트엔티티를 가짐

4. Repository 레포지토리

• 도메인 모델의 영속성 처리를 위해선 물리적 저장소에 도메인 객체를 보관해야함
• 구현을 위한 도메인 모델 (요구사항에서 도출되는 도메인 모델: 엔티티/밸류)
• 애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능을 제공
• ex. DBMS 테이블에서 엔티티 객체를 로딩하거나 저장하는 기능 제공

5. Domain Service 도메인 서비스

• 특정 엔티티에 속하지 않은 or 여러 엔티티와 밸류를 필요로 하는 도메인 로직을 제공하는 경우
• ex. 할인 금액 계산 - 상품/쿠폰/회원등급/구매금액 ...
• 도메인 모델의 엔티티 vs DB 테이블의 엔티티
  • 차이점 1) 도메인 모델의 엔티티는 데이터와 더불어 도메인 기능을 함께 제공
  • 차이점 2) 도메인 모델의 엔티티는 밸류 타입을 이용해서 개념적으로 하나인 데이터드를 묶을 수 있음

모듈 구성

• 아키텍쳐의 각 영역은 별도 패키지에 위치
  • (aggregate 별로) ui / application / domain / infrastructure
    • domain 이 크면 하위 도메인별로 모듈을 나눈다.

*한 패키지에 가능하면 10개 미만으로 파일 개수를 유지