ghojeong/ddd-strategic-design

ddd-strategic-design's Issues

BOUNDED CONTEXT 중심의 패키지 구조로 리팩터링하기

계층 우선 패키지 구조를 BOUNDED CONTEXT 중심의 패키지 구조로 리팩터링한다.

Package by feature, not layer

PR 링크 정리

• next-step#66
• next-step#75
• next-step#79

패키지 구성과 관련된 여러 자료

내가 했던 방법 : Root Aggregate 기준으로 바운디드 컨텍스트를 나누기

* domain : domain layer 
    - aggreagte, repository, domain service 와 같이 도메인에서 처리하는 클래스들을 위치 시키는 편입니다.
* application : application laeyr 
    - 응용 서비스(application service)를 모아두곤 합니다. 
* api : presentation layer 
    - controller, adaptor와 같이 외부 client의 요청을 받는 클래스를 모아둡니다. 
* infra : infrastructure layer 
    - 이메일, 메시지 알림등과 같은 외부 서비스와 관련된 클래스를 모아둡니다.
* dto
    - request, response, layer 간 데이터 이동을 위한 클래스를 정의합니다. 

• https://github.com/cheese10yun/spring-guide/blob/master/docs/directory-guide.md

• https://en.wikipedia.org/wiki/Package_principles

• https://medium.com/@ssowonny/package-by-feature-in-clean-architecture-projects-e14d25e3905e

• http://www.javapractices.com/topic/TopicAction.do?Id=205

• 마틴 파울러; Bounded Context

2021년 8월 24일 화 수업 내용

도메인 분석

• 주문 도메인

• 주문 테이블 도메인

• 메뉴 도메인

• 상품 도메인

• Core Domain : 주문

• Support Domain: 주문테이블, 메뉴, 상품

• Common Domain : 비속어 필터

도메인을 나누는 것의 의미

• MSA -> 독립된 서비스가 된다.

• 모놀리식 -> 패키지가 된다.

• 멀티모듈 -> 모듈이 된다

• 조용호 우아한 객체지향

• 박용권 잘키운 모노리스

도메인 분석이 어렵다면 해외 서비스의 FAQ 페이지를 참고하자.
하나의 CS 팀이 모든 질문을 답할 수 없기 때문에, 나누어져 있는데
나눈 기준이 보통 도메인이 된다.

오늘 수업

Value Object 는 불변이다.
도메인 vs 모델:

• 모델(프라모델) 관심을 가지는 모양 (자바에서 모델은 클래스와 실제로 대응된다.)
• 도메인은 정말 넓은 "영역" (한 도메인에 여러개의 모델을 가진다.)
• 컨텍스트과 도메인은 n:m 관계이다. 컨텍스트는 용어가 다른 의미를 가지는지 구분짓는 역할을 한다.

• seq: 비즈니스 적으로 의미가 없는 식별자. -> Value Object
• id: 비즈니스적으로 의미가 있는 식별자 -> Entity

DDD 어려워하는 3가지

• Bounded Context
• Aggregate
• Domain Service

어휘 정리

• 컨텍스트: 용어사전의 용어의 의미가 달라질 수 있는 "맥락"

• 도메인: 모델들을 나누는 "영역", 도메인을 나눈 기준에 따라 앱의 책임을 쪼갤 수 있다.

  • MSA: 도메인을 기준으로 마이크로 서비스를 쪼갠다.
  • 모놀리식: 도메인을 기준으로 패키지를 쪼갠다.
  • 멀티모듈: 도메인을 기준으로 모듈을 쪼갠다.

• 모델: 도메인에 속한 실제 "관심사", java 에서는 클래스와 1대1 대응된다.

• 엔티티: 비즈니스 적으로 의미가 있는 ID 를 가진 객체

• VO: 불변 객체. 비즈니스 적으로 의미가 있는 식별자를 갖지 않는다. 그래서 id 대신 seq 로 객체를 식별한다.

• Aggregate

  • 어그리게잇이 곧 트랜잭션 단위
  • 비즈니스 일관성이 지켜져야 하는 VO 와 엔티티를 어그리게잇으로 묶는다.
  • 어그리게잇 단위로 ACID 와 생명주기가 맞춰진다.

• Repository

  • 어그리게잇의 트랜잭션을 가능케하는 실제 구현체
  • 리포지토리는 어그리게잇 단위로 존재하고, 테이블 단위로 존재하지 않는다.

• Domain Service

  • 상태가 없이 행위만 가지고 있는 클래스
  • Component 어노테이션을 주로 붙인다.
  • 한 어그리게잇에 넣기 애매한 로직을 도메인 서비스로 분리함
    • 위키로 관리해야하는 비즈니스 정책은 도메인 서비스이다.

전술적 설계 - Aggregate 와 Repository

Aggregate

• ** 어그리게잇이 곧 "트랜잭션" 단위다. **
• ACID 를 지켜야하는 혹은 생명주기를 맞춰야 하는 VO 와 엔티티를 어그리게잇으로 묶는다.
• 어그리게잇 단위로 비즈니스 일관성이 지켜진다.
• 어그리게잇이 곧 Building Block 이 된다.

Root Entity == Aggregate Root

• Root Entity 의 ID 를 Global 식별자라고 부른다.
• 반대로 Root 가 아닌 Entitiy 의 ID 는 Local 식별자라고 부른다.
• Global 식별자를 가진자가 Aggregate Root 가 된다.

Repository

• 일관성을 지켜주는 구현체
• 어그리게잇 단위로 CRUD 의 ACID 를 지켜주는 구현체
• 리포지토리는 어그리게잇 단위로 존재하고 테이블 단위로 존재하지 않는다.

도메인 서비스

• 상태가 없이 행위만 가지고 있음
• 한 어그리게잇에 넣기 애매한 로직을 도메인 서비스로 분리함
  • 위키로 관리해야하는 비즈니스 정책은 도메인 서비스이다.