search

juniors-dev-study / domain-driven-design

1 stars 0 forks source link

15장 디스틸레이션 #17

Closed bearics closed 3 years ago

bearics commented 3 years ago

Distillation

: 혼합된 요소를 분리해서 본질을 좀더 값지고 유용한 형태로 뽑아가는 과정 image

CORE DOMAIN 핵심도메인

: 애플리케이션 모델의 중심적인 모델

GENERIC SUBDOMAIN : 일반 하위 도메인

: 현재 진행중인 프로젝트를 위한것이 아닌, 응집력있는 하위 도메인을 식별하라.

DOMAIN VISION STATEMENT 도메인 비전 선언문

: 핵심 도메인을 짧게 기술하고, 그것이 가져올 가치에 해당하는 '가치제안'을 작성하라. (약 한페이지분량)

ex ) 모델은 프로세스에 필요한 인력자원을 포함하지는 않지만, 공정방법을 내려받아 선택적인 프로세스 자동화가 가능해야한다.

HIGHLIGHTED CORE 강조된 핵심 <디스틸레이션 문서>

: CORE DOMAIN과 CORE의 구성요소 사이에서 일어나는 상호작용을 기술하는 간결한 문서작성하라.(3~7p분량)

COHENSIVE MECHANISM 응집력있는 메커니즘

: 개념적으로 응집력있는 매커니즘을 별도 경량 프레임워크로 분할하라. (특히 잘 문서화된 알고리즘)

SEGREGATED CORE 분리된 핵심

: 일반적이거나 보조적인 역할을 하는 하는 구성요소를 다른 객체로 추출해서 다른 패키지에 배치하라.

그럼 이게 새로운 CORE DOMAIN이 되는건가??

화물 해운 모델 예시

  1. DOMAIN VISION STATEMENT를 살펴보니, 결제와 관련된 역할은 보조적인것에 불구하므로, Billing 패키지를 분리한다.
  2. 화물인도,취급이 가장 중요하므로 Delivery 를 분리해 SEGREGATED CORE로 만든다.
  3. '고객계약' 객체의 역할이 '고객' 객체의 역할을 대신하게 되었으므로, 'Customer' 도메인을 분리할 수 있다.
  4. 'Delivery' : SEGREGATED CORE / 'BILLING' : GENERIC SUBDOMAIN / 'Customer' , 'Shipping' : 모듈로 분리

ABSTRACT CORE 추상화된 핵심

: 모델의 가장 근본적인 개념을 식별해서 그것을 별도의 클래스나 추상클래스, 또는 인터페이스로 추출하라.

리팩터링 대상의 선택

1순위는 CORE DOMAIN , 분해하고 CORE의 격리를 개선하는등 디스틸레이션 해본다. 2순위는 CORE와 지원요소와의 관계가 관련되어있는 곳.

chanhyeong commented 3 years ago

CORE DOMAIN

애플리케이션의 목적에 중심적인 모델

CORE DOMAIN 을 찾아서 support 하는 모델과 코드로부터 분리, 작게 유지

누가 ?

기술적인 팀원이 도메인 지식을 갖춘 경우는 거의 없다 - 도메인 지식을 보조 컴포넌트로 배정하는 경향 오랜 기간 팀에 참여하고 도메인 지식에 관심있는 능력있는 개발자 + 업무를 깊이 알고 있는 도메인 전문가

GENERIC SUBDOMAIN

전문 지식이 아닌 복잡성을 더하는 모델, 부수적인 요소

진행 중인 프로젝트를 위한 것이 아닌 응집력 있는 하위 도메인 -> 추출하여 별도 모듈에 배치, 해당 모듈에는 전문성이 없음

하위 도메인이 분리되고 나면 이후 개발은 CORE DOMAIN 보다 낮은 우선순위 부여 핵심 개발자를 배치하지 않음 (개발자가 도메인 지식을 얻지 못함)

기성 솔루션이나 공표된 모델을 고려

예제

핵심이 아닌 시간대와 같은 것에 중요한 사람을 배치해선 안된다 ❓ 443p 해운에서 불리한 점에 들어간 내용은 뭐지. 계약직이 했는데?

보조적인 성격의 문서를 활용하기

DOMAIN VISION STATEMENT HIGHLIGHTED CORE

DOMAIN VISION STATEMENT

CORE DOMAIN 을 짧게 기술하고 가치에 해당하는 "가치 제안"을 작성

도메인 모델이 어떻게 다양한 관심사를 충족하고 균형을 이루는지

HIGHLIGHTED CORE

CORE DOMAIN 을 잘 보이게끔 모든 사람이 CORE DOMAIN 을 쉽게 알 수 있게 하는 것

디스틸레이션 문서

CORE DOMAIN 과 CORE 의 구성요소 사이에서 일어나는 상호작용을 매우 간결한 문서로 작성 비기술 팀원도 이해할 수 있는 문서

관리되지 않을 수도, 아무도 읽지 않을 수도, 문서가 복잡해질 수도 있음 (그래서 최소, 간결을 지향)

-> 예전부터 아이디어이긴 한데, 문서에 커밋 해시를 비교하게 해서 변경이 일어나면 문서도 같이 수정해야하는지 체크하는 기능이 있으면 좋을 것 같은데. 여기서 중요한 내용은 아니니 스킵

프로세스 도구로써 활용 모델 변경의 중요성을 나타내는 실질적인 지표

표시된 (Flagged) CORE

모델 저장소에 있는 CORE DOMAIN 의 구성요소에 설명 말고 표시 개발자가 힘들이지 않고도 CORE 의 안/밖을 알 수 있게

COHESIVE MECHANISM

how 에 대한 것을 lightweight framework 로 분리 INTENTION-REVEALING INTERFACE 로 프레임워크의 기능 노출

(생각) INTENTION-REVEALING INTERFACE 로 노출하는건 약간 spring-data-commons 와 실제 구현이 분리되어 있는 느낌

GENERIC SUBDOMAIN 과의 차이?

둘 다 CORE DOMAIN 의 부담을 덜어내지만, GS 는 도메인의 관점, CM 은 도메인이 아닌 계산 등

SEGREGATED CORE

GENERIC SUBDOMAIN 을 추출하는 방식으로 도메인에서 일부 CORE 를 불분명하게 만드는 세부사항을 제거해 CORE 를 눈에 띄게

보조적인 역할에서 CORE 개념을 분리 -> CORE 와 다른 코드와의 결합을 줄임 -> CORE 의 응집력 강화

개인적인 정리 - GENERIC SUBDOMAIN 과 SEGREGATED CORE 차이

GS 는 CORE 에서 표현하는 것과 거리가 먼 개념 (배송 알림 등) SC 는 CORE 가 너무 클 때 뜯어내는 개념

ABSTRACT CORE

수직적 (MODULE) 보단 수평적 (ABSTRACT) 으로 자르기

모델의 가장 근본적인 개념을 식별 -> 별도의 클래스 or abstract or interface 로 추출

개인 의견

abstract class 에 들어가는건 별로인 것 같다 실제 어떤 값이 있는지가 구현한 클래스에서 바로 보이지 않음. ArticleVO 같은..

bearics commented 3 years ago

GENERIC SUBDOMAIN

p443. 일반화가 재사용 가능하다는 의미는 아니다.

  • 왜 갑자기 재사용이 나오는거지? 그냥 코어 도메인에서 조금 덜 중요한 도메인을 뺀게 일반 하위 도메인 아닌가?? 이거를 재사용??
  • 그냥 엄청 보편적인 솔루션을 만들어 여러 프로젝트에서 재사용한다는건가??

HIGHLIGHTED CORE

p449. CORE DOMAIN과 CORE의 구성요소 사이에서 일어나는 상호작용을 기술하는 매우 간결한 문서를 작성하라.

SEGREGATED CORE

p458. CORE를 분리하며, 다른 CORE와 결합을 줄여 응집력을 강화하라

y2o2u2n commented 3 years ago