CSMSA

MSA이론1. Domain-Driven Design / Aggregates

Implementing Domain-Driven Design For Microservices Architecture

DDD의 원칙

Values: Meaning, Unity, Usability, Fitness, Flexibility, Maintainability
Principles: Continuous Learning, Knowledge Rich Design, Ubiquitous Language, Model-Driven Design, Separation of Concerns
Deep Models, Declarative Style
Patterns:
Layered Architecture
Ubiquitous Language (Entities, Value Objects, Services, Modules, Aggregates, Factories, Specification) /
Supple Design (Intention-Revealing Interfaces, Side-Effect Free Functions, Assertions, Conceptual Contours, Standalone Classes, Closure of Operations)

What is Domain Driven Design

도메인 전문가, 기술 전문가가 소프트웨어 개발를 위해 협엽하는 기술
아이디어와 도메인은 공통언어를 통해 코드에 반영되어야 한다.
Domain Driven Design 에 대해 알아보기 위해 다양한 Domain에 대해 알아보자.

Domain?

팀은 특정 비즈니스 도메인에 맞게 일한다.
팀은 비즈니스 도메인에 초점을 맞춘다
도메인의 세부사항은 팀의 포지션마다 다르다.

도메인의 예시
Hotel / Banking / Mortgage / Credit / Debit Accounts / Credit Cards / Retails loans

Subdomains

  • 도메인은 서브도메인으로 구성된다.
  • 서브도메인은 Bounded Context와 유사하며 이는 서로 커뮤니케이션할 수 있다.
  • 서브도메인은 또다른 서버도메인을 포함할 수 있다.

Core domain

  • 돈을 벌게해주는 중요한 도메인
  • 경쟁업체와 높은 차별성을 갖음

Supporting Subdomain

기술적으로 서포팅하지만 COTS-Software가 아니다.
외부지원으로 구현될수 있지만 사내 팀이 주도해야 한다.

Commercial, off-the-shelf
COTS 란 완성품으로 일반 대중에게 판매, 대여 또는 권한을 부여할 수 있는 컴퓨터 소프트웨어나 하드웨어, 기술 또는 컴퓨터 제품 등을 의미한다.

Generic Subdomain

Suitable for Outsourcing, COTS

Bounded Contexts

큰 도메인을 작은 Context로 나눈것.
각각의 Context는 자신만의 공통언어, 모델을 갖을 수 있다.
또한 Bounded Contexts는 일부 도메인을 공유할 수 있다.
Ubiquitous Language(공통언어)로 모델되어야 하며 프로그램에서 비즈니스 니즈를 정의한다.

This is Domain Driven Design

DDD의 Concepts and Overview

Domain-Driven Desigin은 기본 비즈니스 이해에 중점을 둔 소프트웨어 디자인방식이다.
이러한 접근방식은 다음 두가지 전제를 둔다.

  • 복잡한 도메인 디자인은 모델을 기반으로 한다.
  • 대부분의 소프트웨어 프로젝트는 도메인 및 도메인로직에 중점을 둔다. (시스템 구현을 위한 특정 기술에 중점을 두는것이 아님)

전통적인 Layered Architecture

User Interface: 정보를 보여주고 사용자의 명령을 해석
Application : 비즈니스 rule,지식 미포함 / 작업 조율 그리고 도메인에 작업 위임역할
Domain : 비즈니스로직, 룰 포함/ 소프트웨어의 심장부
Infrastructure : 상위 레이어를 지원하는 기술제공

Domain-Driven Design with Onion Architecture

Core: 특정 도메인이나 기술에 국한되지 않는 building blocks로 볼 수 있다. 예로 List, Maps, Case Classes, Actor and Lenses가 있다.
Domain : 공통언어를 통해 작성된 비즈니스 로직 관련 메소드, 클래스가 상주하는 영역이다.
API : 도메인의 진입점 역할을 한다. API는 도메인을 조작하지 못하도록 immutable한 객체만 노출해야 한다. 코어, 도메인은 API에 액세스할 수 있지만 Infrastructure는 API에 액세스할 수 없다.
Infrastructure : DB, 사용자 인터페이스 같은 다얗안 기술을 포함하는 가장 바깥쪽 영역이다. 모든 영역은 Infrastructure 영역에 접근 할 수 있다.

Bounded Contexts 에 대해 자세히 알아보자

전체 비즈니스 모델은 너무 커 한번에 이해하기 힘들다. Bounded Contexts는 서로 다른 모델간 경계와 관계를 표현하기 위해 존재하는 명시적인 경계로서 경계 내의 Ubiquitous Language는 특정한 의미를 갖는다.

Bounded Context의 구현

  • Bounded Context당 한팀이 존재한다.
  • 코드 Repository가 Bounded Context마다 존재한다.
  • Domain Model + DB Schema + UI + Web Services (API)로 구성된다.

Bounded Context는 Ubiquitous Language와 domain model을 캡슐화하나 도메인 모델과 상호작용하는 것, 도메인 모델을 서포트 하는 기능을 포함한다.

또한 Bounded Context안에 Aggregates Entity(유니크한 트랜잭션), Value Object(불변의 객체)가 존재하는데 이는 바로 뒤에서 설명하니 참고하도록 하자.

What are Entities?

Domain object를 엔티티로 정의하는데 그것은 제각각 다르다. 또한 엔티티의 정체성을 적절히 결정하고 어떻게 가져올지 결정한다.
최종 사용자,각 어플리케이션,data store은 identity를 만들어낸다.

Aggregates

Aggregates는 루트엔티티로 간주되는 연관된 객체 그룹이다. (트랜잭션과 같음)

Aggregates의 특징

  • 트랜잭션과 마찬가지로 Atomic, Consistent, Isolated, Durable 특징을 갖는다.
    (사람모형 레고는 2개의 팔, 다리, 얼굴을 갖는데 이를 Product’s Invariant(불변성)이라 한다.)
  • 경계가 명확하다.(외부 개체는 신경쓰지 않음)
  • 내부 개체를 보호한다. 외부개체는 루트 Aggregates를 통해 접근 가능하며 Aggregates의 상태는 변경 불가능하다.
  • Aggregates는 자신이 소유한 entity, value object들의 무결성을 보호해야할 책임이 있다.
1
2
3
4
5
6
7
8
9
10
11
@Entity
public class Cart implements Aggregate {
  @EmbeddedId
  private CartId id;
  @Embedded
  private CustomerId customerId;
  @OneToMany(cascade = CascadeType.All, orhanRemoval = true)
  @JoinColumn(name="cartId")
  private Set<CartItem> items;
}

위와같은 코드가 있을 때 cart id는 루트 엔티티 이다. 또한 CartItem이라는 엔티티들의 레퍼런스를 갖고 있으며 CustomerId를 ValueObject로서 사용한다.

Aggregates rule

  1. 모델은 불변해야 하며 일관되게 경계안에 있어야 한다.
  2. Aggregates 작게 디자인해라.(클 경우 확장성 저하 가능성)
  3. 다른 Aggregates참조는 Identity로 하라.
  4. 경계밖에서의 일관성유지

Relationships Between Aggregate

RelationshipsBetweenAggregate

Aggregate Root만 다른 Bounded Context의 Aggregate Root에 접근 가능

Aggregate 팁

  • Aggregate는 항상 정답이 아니다.
  • Aggregates는 루트와 연결될 수 있다.
  • 루트가 아닌 엔티티를 FK로 사용하는것을 간과하지 마라.

Aggregates가 중요한 이유

개체를 그룹화하고 카테고리화 하면 복잡한것을 쉽게 관리할 수 있다.
주인없는 레코드를 방지하여 GC가 쉬워진다.
DB와의 고수준의 통신이 가능케한다.

Value Object

가능한 엔티티 대신 값 개체를 사용하여 모델을 작성해야 한다.
Value 인지 아닌지 결정하기위해 다음 것들을 확인해보자.

  • 도메인을 측정하고, 정량화 할수있는지
  • 불변의 상태로 유지될 수 할수있는지
  • 관련된 속성을 필수 단위로 하여 전체를 구성하는지
  • 상황이 바뀌면 교체 가능한지.
  • Value를 사용하는 다른값과 비교될 수 할수있는지
  • collaborators에게 부작용을 없는 행동을 하는지

What are Domain Services

도메인의 일부는 객체로 모델링하는것이 자연스럽지 않다.
Application Service와 다르다. Application Service는 Domain Service의 클라이언트다.
일반적인 사용 예

  • 성능이 중요한 비즈니스 프로세스
  • 도메인 객체를 다른것의 구성요소로 변환할 때
  • 둘 이상의 도메인 객체에서 입력을 요구할 때

Domain Building Blocks

Entity :

  • identity가 있는 명사
  • 가변적이며 다른 엔티티 혹은 value object와 연관될 수 있다.
  • 공유될 수 없다.

Value Object :

  • identity가 없는 명사
  • 불변하며 다른 엔티티와 연관될 수 있다..
  • 공유될 수 있다.

Aggregate :

  • 하나의 Aggregate당 하나의 root entity가 있다.
  • 관련있는 Aggregate는 루트 entity를 통해 참조할 수 있지만 Aggregate의 다른 entity는 참조할 수 없다.
  • 모든 작업은 루트를 통해 수행된다.

Service :

  • 서비스는 어플리케이션에서의 액션이다.
  • 서비스는 엔티티의 상태변화를 일으킨다
  • 서비스는 상태가 없다.
  • 서비스는 어플리케이션,도메인, 인프라스트럭쳐의 어느 곳의 일부가 될 수 있다.

Factory :

  • 엔티티나 value object를 생성한다
  • 엔티티의 생성이 복잡할 때 사용한다.

DDD의 이점

  • 기술보다는 비즈니스에 초점을 맞춘다,
  • 코드르 재사용하고 읽기 쉽다.
  • 개선사항이 있을 때 유연하다.

성공적인 DDD

  • 도메인전문가, 기술 전문가의 협업을 통해 모델 빌드
  • 어플리케이션의 반복적인 빌드
  • 테스트하고 테스트하고 또 테스트하라

세계지도에서 DDD가 어떻게 적용되는지 보자.

Model Driven Desigin
Domain = Word Map
Sub domain = 오세아니아, 아시아, 북아메리카,….
Bounded Context = Countries(South Korea)
Ubiquitous Language = Korean Language
Domain Model = Map of Korea

Share