kok202
도메인 주도 설계 (1/3) 요약

2022. 4. 3. 18:32[공부] 독서/DDD (도메인 주도 설계)

http://www.yes24.com/Product/Goods/5312881

 

도메인 주도 설계 - YES24

소프트웨어의 복잡성을 다스려라!소프트웨어의 복잡성은 도메인에서 기인하고, 그러한 복잡성을 어떻게 다루느냐가 프로젝트의 성패를 좌우한다. 도메인 주도 설계(Domain-Driven Design)는 복잡한

www.yes24.com

 

요약

Model driven design 에서 모델을 표현하는데 Entity 를 사용한다.

Model driven design 에서 모델을 표현하는데 Value Object 를 사용한다.

Model driven design 에서 모델을 표현하는데 Service 를 사용한다.

Model driven design 에서 모델을 표현하는데 Module 을 사용한다.

Model driven design 에서 모델을 표현하는데 Intention revealiing interface 를 사용한다.

Model driven design 에서 번역을 단순화 하는데 Standalone class 를 사용한다.

Model driven design 에서 변경 비용을 줄이는데 Conceptual contour 를 사용한다.

Model driven design 에서 도메인을 격리하는데 Layerd architecture 를 사용한다.

Value Object 를 캡슐화하는데 Factory 를 사용한다.

Value Object 를 캡슐화하는데 Aggregate 를 사용한다.

Entity 를 캡슐화하는데 Factory 를 사용한다.

Entity 의 무결성을 유지하는데 Aggregate 을 활용한다.

Entity 를 접근하는데 Repository 를 활용한다.

Aggregate 을 캡슐화하는데 Factory 를 사용한다.

Aggregate 를 접근하는데 Repository 활용한다.

Service 에 새로운 이름을 추가하면 Ubquitous language 가 된다.

Value Object 에 새로운 이름을 추가하면 Ubquitous language 가 된다.

Entity 에 새로운 이름을 추가하면 Ubquitous language 가 된다.

Module 에 새로운 이름을 추가하면 Ubquitous language 가 된다.

Ubquitous language 를 소리내어 모델링하면 Model driven design 이된다.

Intention revealiing interface 의 이름의 출처는 Ubquitous language 다.

Intention revealiing interface 를 안전하고 단순하게 하면 Side effect free function 이 된다.

Intention revealiing interface 의 부수효과를 명확히하려면 Assertion을 사용한다.

Assertion 의 컴포지션을 안전하게 만들면 Side effect free function 이 된다.

 

Model driven design 의 유효성 정의 범위를 결정지으면 Bounded context 가 된다.

Bounded context 에 새로운 이름을 추가하면 Ubquitous language 가 된다.

Bounded context 의 단일화를 유지하는데 Continous intergration 이 사용된다.

Ubquitous language 에서 참조로 모호함을 제거하면 Bounded context 가 된다.

Ubquitous language 를 소리내어 모델링하면 Core domain 이 된다.

Core domain 을 강조하면 Ubquitous language 이 된다.

Core domain 의 방향을 제시하는데 Domain vison statement 가 사용된다.

Core domain 에서 벗어날 대상으로 인식되면 Generic subdomain 이된다.

Core domain 의 재패키지화된 결과는 Segregated core 가 된다.

Core domain 을 구조화하는데 Evolving order 를 활용할 수 있다.

Core domain 의 이질적인 부분을 연결해주는 것을 Context map 이라 부른다.

Generic subdomain 을 디스틸레이션하면 선언적 형식이 된다.

Segregated core 을 디스틸레이션하면 선언적 형식이 된다.

Evolving order 에 구조를 도입하면 Ubquitous language 가 된다.

Evolving order 에 개념을 추가하면 Core domain 이 된다.

Context map 을 구조화하는데 Evolving order 를 활용할 수 있다.

 

분류

분류 개념
핵심 Ubquitous language
Model driven design
Core domain
개념 Entity
Value object
Service
Repository
Module
캡슐화 Factory
Aggregate
컨텍스트 Bonded context
Context map
구조화 Layered architecture
Evolving order
관심사의 분리  Generic subdomain
Segregated core
선언적 형식
디스틸레이션
단순화 Standalone class
안정화 순수 함수
Assertion

 

용어 설명

개념 설명
Aggregate 데이터 변경을 목적으로 하나의 단위로 다뤄지는 연관 객체의 모음.
Aggregate 의 구성 요소중 하나는 루트로 지정되고 외부 참조를 위해 사용됨.
Analysis pattern 업무 모델링의 공통적인 구성물을 나타내는 개념의 그룹
Assertion 프로그램의 동작 방식과는 독립적으로 프로그램이 어떤 시점에 지녀야할 상태를 나타내는 문장.
연산의 결과, 구성요소의 불변성을 명시.
Bounded context 특정 모델에 포함된 범위가 정해진 적용 가능성.
어떤 것이 일관성을 지녀야하고 독립적으로 개발 가능한지를 분명하게 이해할 때 나오는 개념.
Cohension 논리적인 합의와 의존성
Command 시스템에 변화를 초래하는 연산
의도적으로 부수 효과를 만들어내는 연산
Conceptual contour 개념 윤곽.
도메인 자체의 근원적인 일관성.
Context 단어나 문장이 해당 의미를 결정한다고 보여지는 환경
Context map Bounded context 간의 실제 관계를 표현하는 것
Core domain  중심적인 열학을 수행하고 애플리케이션을 차별화, 가치있게 만드는 모델
Declarative desgin 특성에 대한 정확한 기술이 실제 소프트웨어를 제어하는데 수단이 되는 프로그래밍의 형태
Deep model  도메인의 초보적 해석을 벗어나 도메인 전문가의 주된 관심사와 가장 깊은 지식을 적확하게 표현한 모델
Distillation 가치있고 유용한 형태로 본질(Core domain)을 추출할 목적으로 구성요소를 분리하는 과정
Domain 지식이나 영향력, 활동의 영역
Domain expert 프로젝트에서 부여된 임무가 소프트웨어 개발이 아니라 애플리케이션 도메인인 구성원
Domain layer Layered architecture 에서 도메인 로직을 책임지는 설계와 구현에 해당하는 부문
Entity 근본적으로 속성이 아니라 연속성과 식별성의 맥락으로 정의되는 객체
Factory 생성 로직을 캡슐화하고 생성된 객체 타입을 추상화하는 메커니즘
Function 부수효과 없이 결과를 계산, 반환하는 연산
Immutable 생성후 식별 가능한 상태가 절대 바뀌지 않는 특성.
Implicit concept 모델이나 설계의 의미를 이해하는데 필요하지만 결코 언급되지 않는 개념
Intentional reveling interface 클래스, 메소드, 컴포넌트의 이름이 최초 개발자의 의도를 나타내고, 클라이언트 개발자 의미있는 가치를 전달하는 설계
Invariant 메소드 실행중이나 아직 커밋되지 않은 DB transaction 같이 일시적인 상황을 제외하고 항상 작업을 보장받는 특정 요소에 대한 Assertion
Large scale structure 전체 시스템에 대한 설계 패턴을 수립하는 일련의 고수준 개념이나 규칙.
시스템을 넓은 안목에서 논의하고 이해할 수 있게 도와주는 언어
Layered architecture 소프트웨어 시스팀의 관심사, 특히 도메인 계층을 격리해서 관심사를 분리하는 기법
Life cycle 객체가 생성되어 소묠되기 까지 취하는 일련의 상태.
일반적으로 life cycle 은 하나의 상태에서 다른 상태로 변경될 때 무결성을 보장하는 제약조건을 포함함.
시스템과 다른 Bounded context 간의 Entity 이동을 포함할 수 있음
Model 도메인의 선택된 측명을 기술하고 도메인과 관련된 문제를 해결하는데 사용할 수 있는 추상 체계
Model driven design 소프트웨어 요소의 일정 부분이 모델의 요소에 밀접하게 대응되어 있는 설계
Modeling paradigm 도메인에 담긴 개념을 찾아내는 특정 형식.
Repository 객체 커랙션을 흉내내어 CRUD 행위를 하는 캡슐화 메커니즘
Responsibility 작업을 수행하고 정보를 알아야할 의무를 표현한 개념
Service 캡슐화된 상태가 없으며 모델에 홀로 존재하는 인터페이스로 제공되는 연산
Side effect 의도적인 갱신 여부나 고의적인 갱신 여부와 관계없이 연산 결과로 발생하는 모든 식별 가능한 상태 변화
Side effect free function = function
Standalone class 시스템의 기본 기능과 기본 라이브러리를 제외하고 다른 어떤 것도 참조하지 않은 상태로 이해, 테스트 될 수 있는 클래스
Stateless 어떤 컴포넌트의 history 와 관계없이 모든 연산을 사용할 수 있는 설계 요소의 특성.
Stateless 컴포넌트는 전역적으로 접근이 가능하고, 변경도 가능하지만 컴포넌트의 행위에 영향을 주는 private state 를 유지하지는 않음.
Strategic design 시스템의 큰 부분에 적용되는 모델링과 설계 결정.
Supple design Deep model 에 내재된 가치를 클라이언트 개발자에게 예상되는 결과로 명확하고, 효과적이며 유연한 표현이 가능하도록 만드는 설계 방식. 
Ubiquitous language 도메인 모델에 따라 구조화 되어 모든 팀원이 소프트웨어와 팀 활동을 하는데 사용하는 언어
Unification 언어가 모호하지 않고 어떠한 규칙도 모순되지 않는 모델의 일관성
Value Object 일부 특징과 속성을 기술하지만 식별 가능하지 못하는 객체
Whole value 다하나의 완전한 개념을 모델화한 객체