티스토리 뷰

Programming/DDD

Layered Architecture

Albothyl 2019. 8. 3. 21:38

1. Project Structure

- 회사, 팀 등 개발 목적과 규모에 따라서 틀려진다. 때문에 무조건 DDD가 좋다고 할 수 없다.

 

 

2. DDD Detail (3-2 기준)

 

1. Interface

- 사용자나 컴퓨터 시스템에게 정보를 보여주고 사용자의 명령을 해석하는 일을 책임진다.

 

2. Application

- 소프트웨어가 수행할 작업을 정의하고 표현력 있는 도메인 객체가 문제를 해결하게 한다. 이 계층에서 책임지는 작업은 업무상 중요하거나 다른 시스템의 응용 계층과 상호작용하는 데 필요한 것들이다. 이 계층은 얇게 유지된다. 여기에는 업무 규칙이나 지식이 포함되지 않으며, 오직 작업을 조정하고 아래에 위치한 계층에 포함된 도메인 객체에게 작업을 위임 한다. 업무 상황을 반영하는 상태가 없지만, 사용자나 프로그램 작업에 대한 진행상황을 반영하는 상태를 가질 수는 있다.

public Long orderDiscount(Long orderId, Long couponId) {
   final Order order = orderFinder.findOne(orderId);
   final Coupon coupon = couponFinder.findOne(couponId);

   OrderDiscountDomainService.calculate(order, coupon);
}

 

3. Domain

- 업무 개념과 상황에 관한 정보, 업무 규칙을 표현하는 일을 책임진다. 이 계층에서는 업무 상황을 반영하는 상태를 제어하고 사용하며, 상태 저장과 관련 된 기술적인 세부사항은 인프라스트럭처에 위임한다. 이 계층은 업무용 소프트웨어의 핵심이다.

public Long calculate(Order order, Coupon coupon) {
   //Order에서 직접 Coupon을 조회하여 처리하지 않는다.
      ...
}

 

4. Repository

- MySQL, MongoDB, Casandra 등등 DB 구현체 Module

- Repository Module이 변경되어도 Domain Module에는 영향이 없어야 한다.

 

5. Infra

- 상위 계층을 지원하는 일반화된 기술적 기능을 제공한다. 이러한 기능에는 애플러케 이션에 대한 메시지 전송, 도메인 영속화, UI에 위셋을 그리는 것 등이 있다. 또한 인프라스트럭처 계층은 아키텍처 프레임워크를 통해 네 가지 계층에 대한 상호작용 패턴을 지원할 수도 있다.

 

 

3. Layerd Architecture

복잡한 프로그램을 여러 개의 계층으로 나눈다. 

- 응집력있고 오직 아래에 위치한 계층에만 의존하는 각 계층에서 설계를 발전시킨다. 

- 표준 아키텍처 패턴에 따라 상위 계층과의 결합을 느슨하게 유지한다. 

- 도메인 모델과 관련된 코드는 모두 한 계층에 모으고 사용자 인터페이스 코드나 애플리케이션 코드, 인프라스트럭처 코드와 격리한다.

- 응용 계층이 아닌 도메인 계층에서 주요 업무 규칙을 책임지고 있다.

- 도메인 계층에서 도메인 모델을 표현하는 것에 집중하면  본질적인 업무 지식을 포착해서 해당 업무 지식이 풍부하고 명확해질 수 있다.

- 계층 분리가 중요한 까닭은 프로젝트에서 인터페이스 자주 교체하기 때문이 아니라 깔끔한 관심사의 분리를 토대로 각 계층의 설계를 이해하고 유지하기가 쉬워지기 때문이다.

 

 

4. 내 생각

- monolithic 구조가 처음에는 빠르게 개발할 수 있어서 좋다. 하지만 어느정도 확장을 고려해서 Project Structure를 결정해야 한다. 때문에 monolithic도 모듈로 분리할 수 있도록 Package를 잘 구분하고, Package간에는 Interface로 추상화 해야 한다. "1. project structure" 에서 1번에서 4번으로 갈 수록 코드의 양도 많아지고 번거롭지만, 확장에는 열러있고, 변화에는 닫혀있다 (OCP 원칙). 여기에서 고민이 되는 부분은 3번과 4번이다. 사실 프로젝트가 만들어지면 DB가 바뀌는 일은 거의 일어나지 않는데 굳이 Repository Module을 분리해야 할까? 특히나 JPA를 사용하고 있다면 굳이 분리할 필요는 없을것 같다.

 

'Programming > DDD' 카테고리의 다른 글

Bounded Context  (0) 2019.08.03
분석 패턴  (0) 2019.08.03
유연한 설계  (0) 2019.08.03
DDD 구성요소  (0) 2019.08.03
Specification Pattern  (0) 2019.07.14
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함