도메인 주도 설계

어플리케이션이 복잡해지는 원인은 기술이 아니다. 사실 대부분의 원인은 해결하려는 도메인의 복잡성 때문이다.

도메인의 복잡성을 정복하면 코드의 복잡성도 줄어든다.

애자일 방법론을 잘하기 위한 맹점은 커뮤니케이션 이며. 도메인 주도 개발은 커뮤니케이션을 원활하게 해준다.

1부 동작하는 모델 만들기

지식탐구

도메인모델은 도메인을 관련자들이 이해하기쉽게 추상화한 모델이다. 예를들면 고대 중국지도 같은 것이다.

사실을 반영하지만, 도메인의 맥락상 그리고 도메인을 이해하는데 중요하지 않은 사실을 전부 반영하지는 않으며. 사람이 이해하기 좋게 강력하게 추상화 되어 있다.

개발자와 도메인전문가가 소통하기 쉽게 해주며 좋은 코드에 기반이 된다.

초기 도메인 모델의 구축은 필수적이다. 복잡한 도메인은 개발자와 도메인 전문가의 커뮤니케이션이 중요하기 때문이다.

이런 과정은 애자일 방법론에 의해 진행되어야 빛을 발한다.

개발자는 도메인에 관심이 없고 기술에만 관심이 있다. 하지만 좋은 앱을 만들기 위해서는 도메인에 대한 의식적이고 지속적인 학습이 중요하다.

도메인 모델이 구체와되어 있으면 개발자 구성원 전체가 도메인에 대한 지식접근이 수월해진다.

도메인 지식 탐구 과정에서는 항상 중요한 도메인 규칙이 발견되므로 이 과정이 매우 중요하다.

의사소통과 언어 사용

도메인 전문가와 개발자가 익숙하게 사용하는 언어는 틀리므로 주의해야한다. 그래서 그들이 사용하는 공통 언어를 만들어야 하는데 그게 도메인 모델이다.

다이어그램 uml같은 도구 외에도 유비쿼터스 언어가 도메인 모델 언어를 담당한다.

도메인언어는 크게 소리내어 읽었을때 기술적 용어가 섞여있으면 안되고 장황하지 않고 간결하게 들려야 한다.

도메인 언어가 자연스럽게 다듬어진 후에 다이어그램을 작성하거나 코드를 짜라.

uml코드와 다이어그램을 도메인잔문가와 함께 보며 이야기 하는것도 좋다.

다이어그램은 보충하여 설명하기 위한 도구일뿐이다. 상세한 부분을 전부 담기는 사실상 어렵고 핵심부분만을 설명해야한다. uml로만은 불충분하고 텍스트 설명이 있어야한다. 요점은 너무 복잡해서는 안된다.

문서는 최소한으로 유지하고, 코드와 대화를 보안하는 목적에 충실해야 한다.

하나의 모델이 구현 설계 의사소통의 기반이 되어야 한다.

설계를 위한 모델은 최소화해야 하지만, 설명을 위한 모델은 보다 유연할 수 있다. 다만 이 둘을 혼동하지 말고 명확히 구분해야 한다. 즉, 코어 설계 모델과 부가적인 설명 모델을 분리할 때 비로소 모델이 명확해진다.

모델과 구현의 연계

모든 설계는 실제로 코드에 구현될때 기반이 되는 유용한 것이어야 한다. 구현과 모델이 따로 논다면 의미가 없다. 이를 실현하려면 모델링 접근법이 필요하다.

모델이 구현에 대해 비현실적이라면 새로운 모델을 만드는게 옳다.

모델과 구현이 따로 놀아서는 안된다.

도메인주도개발은 모델 설계 구현을 단일한 활동으로 정제하는 반복적인 과정이다.

도메인 주도 설계의 장점은 밖으로 드러나지 않는 암묵적 개념을 추상화하여 개발자와 도메인 전문가 문제를 인식할 수 있게 만들어 준다는 것이다. 이걸 내부 드러내기라고 한다.

설계자와 코더가 구분되어 있으면 모든걸 엉망으로 만든다. 지나치게 설계와 구현의 책임을 구분하는 것운 도메인 주도 개발이 아니다.

누가 좋아하건 말건 프로그래머가 곧 모델러다.

모델을 만드는 모든 기술자는 반드시 코드를 구현하는데 어느정도 시간을 투자해야 한다. 그리고 코드를 주로 다루는 사람도 코드를 통해 모델을 표현하는 방법을 모두 배워야 한다.

2부 모델 주도 설계의 기본 요소

정교한 모델은 가장 근본적인 부분에 관심을 집중해야 복잡성을 극복할수 있다.

도메인의 격리

도메인에 관련된 코드를 엄격히 분리해야 복잡성이 줄어든다.

도메인 부분을 소프트웨어의 기술과 관련된 부분과 분리하여 복잡성을 제어하는 것이다.

계층형 아키텍처

도메인을 격리하기위한 효과적인 기법중 하나이다.

도메인규칙과 다른 응용프로그램에 동작에 필요한 규칙이 섞이면 당장은 편하지만 나중에 다시 파악하거나 개선해야할 때 곤란해진다.

각 계층은 단방향으로 흘러야 하며 역으로 순환되면 복잡해진다.

사용자인터페이스 -> 응용 -> 도메인 -> 인프라 스트럭처

위 계층구조가 일반적인 흐름이다.

요지는 응용프르그램에 계층을 잘게 놔눠서 경계를 독립시키는 것이다.

요점은 각 계층간에 인터페이스에 의한 느슨한 연결이다.

상위 계층에서 하위계층으로 단방향으로 참조할수있으며 상위참조는 지양한다.

하지만 상위를 호출해야 할 경우에는 콜백패턴이나 옵저버패턴 같은 계층간에 관계를 맺어주는 아키텍처를 활용할 수 있다.

보통 MVC패턴이러고 부르는 구현체가 대표적인 계충형 설계에 속한다.

프레임워크별로 장단점이 있으므로 상황에따라서 프레임워크를 선택적으로 적용하여 이점을 취하게 구조화하는 것이 가장 이상적이다. 어찌됐든 더 좋은 프레임워크는 계속 나올것이기 때문이다.

도메인주도설계에서는 도메인의 격리만이 가장 중요하다.

이런 계층분리에 반대되는 패턴에는 스마트ui 라는 패턴이 있으며 ui로직에 비지니스로직이 속한 것이다. 이것대로에 이점이 있지만 복잡한 규모의 도메인에서는 효과적이지 않다.

하지만 도메인주도 개발은 높은 개발자의 수준을 요구한다. 그렇지 않다면 도메인 주도 설계가 오히려 힘든 상황이 될수도 있다. 일반작인 간단한케이스엔 스마트UI가 더 좋을수도 있다.

하지만 일단 스마트UI로 패턴이 정해지면 중간에 바꿀수는 없다. 그냥 다시 만들어야 한다.

소프트웨어에서 표현되는 모델

객체간의 연결을 설계하고 구현하는 방법으루 설명한다.

일반적인 상태는 값객체로 표현하는게 좋으며, 값 객체는 연속성이 아이덴티티가 중요하다.

행동이나 연산은 서비스로 구분하여 값객체와 분리하는게 좋다.

연관관계

초기모델은 양방햐유다대다 연관관계가ㅜ많으며… 구현과 유지보수를 어렵계한다. 일반적으로 더루기 쉬운 객체관계는 1.일정한 방향이 있으며 , 2. 한정자를 사용하여 다중석이적고, 3. 꼭 필요한 연관관계만 있다. 무분별한 관계가ㅜ없다.

초기 모델은 양방향 다대다 연관관계가 많다. 하지만 이런 복잡한 관계모델을 유지보수하기란 쉬운일이 아니다.

모델이 고도화 될수록 점점 단방향의 관계를 유도하는게 좋으며, 다중성이 적게 만들고 꼭 필요한 연관관계만 남기는게 좋다.

도메인을 깊게 이해하다보면 자연스럽게 방향이 생기고 한정자가 생기고 연관관계가 꼭 필요한 부분을 위주로 분명해진다.

Entity

어떤 객체는 연속적으로 자신을 증명할 필요가 있는데, 그런 객체를 엔티티라고 부른다. 객체의 생명주기를 결정하는 객체다.

모든 객체가 다 앤티티일 필요는 없다.

소프트웨어에 유의미한 진정한 식별성을 만들려면 도메인을 이해해야한다.

값 객체

모든 객체를 엔티티로 만들 필요는 없다. 그럴려고 하면 너무 복잡해진다.

값객체는 불변으로 다루는편이 좋으며 복잡성을 피할수 있으며 활용적이된다.

예를 들면 주소정보처럼 개별적 완성도를 갖는걸 값객체로 만들면 좋다.

객체는 동등성에 대한 가변성이 있으므로, 블변으로 만드는데 당연하다.

하지만 모든 데이터의 특성이 다 그런건 아니므로 도메인 모델에 따라서 어떤게 적합한지 틀리다.

아무튼 중요한 점은 객체간의 연관관계가 작고 단순할수록 좋은 모델이라는 것이다.

엔티티와 값객체와의 관계는 단방향이이다. 양방항이라면 뭔가 잘못된 것이다.

서비스

행동이나 활동에 의미가 큰 부분들은 값객체나 엔티티로 분류할게 아니라 서비스로 분류해야 옳다.

서비스는 어떤 상태도 갖지 않지만, 도메인 개념과 관련된 행동으로 정의된다.

서비스에는 계층형 아키텍트에서 흔히 도메인 서비스, 응용서버스, 인프라스트럭처 서비스로 구분할수 있다.

서비스는 엔티티와 가변객체를 숨기고 사용자에게 인터페이스만 제공하는 측면에서 활용된다.

서비스는 계층간의 구분을 명확하게 하는데 유용하다. 도메인 규칙을 다른 계층에 스며들지 못하게 제어 가능하게 한다.

모듈(패키지)

도메인 모델이 의미하는 것으로 모듈의 이름을 정의하라. 모듈은 모델과 함께 발전해야 한다.

프레임워크의 모든 기능을 다 활용할 필요는 없다. 도메인 주도 개발에 도움이 되는 것들만 받아들여 사용하면 된다.

보통 프레인워크에는 기술적인 용도의 패키지 분할이 강제되기도 하는데, 그건 도메인 주도 모델에 방하개 되기도 한다. 따라서 최소한의 프레임워크 규칙으 ㄹ따르되 도메인 주도개발에 따라 모듈을 분리 하는게 좋다.

일반적으로 현재까지는 객체지향이 도메인 주도 개발을 적용하기 가장 용이하다. 하지만 다른 패러더임에도 적용가능하지만 객체지향의 사용자가 많아서 사용사례가 많다.

성숙하지 않은 패러다임을 사용하는 것은 여러모로 위험성이 따른다.

도메인 주도 개발을 객체지향 패러다임에서 사용하는 것이 여러모로 현명하나는 말이다.

복합적인 패러다임을 사용할 수는 있지만 많은 요소를 고려해야하며, 병합적으로 사용해야 하는 경우에는 너무 uml에 집착하지 말고 다양한 방식을 유연하게 사용하는게 좋다.

도메인객체의 생명주기

모든 객체에는 생명주기가 있다.

요점은 생명주기 동안 무결성을 유지하며 생명주기의 복잡성으로 모델이 난해하는걸 방재해야 한다.

AGGREGATE (집합체)

집합체는 데이터에 변경 단위로 부르는 연관객체의 묶음을 말한다.

집합체는 루트와 경계로 이루어지며 루트는 entity를 말한다. 경계내의 객체는 참조할수 있지만. 경계외에 객체에서는 루트에만 접근할수 있다.

집합체는 특히 객체들간의 경합문제에 근본적인 해결책이 된다.

팩터리

이런 복잡한 집합체 객체들을 일일이 생성하는건 너무 힘든 일이다.

추상화, 은닉화 해서 객체 사용자가 생성을 쉽게 해야 하는데 이게 바로 팩터리 패턴이다.

결국 팩토리는 복잡한 집합체 객체를 생성하는 책임을 갖는다.

Aggregate를 하나의 단위로 그것들의 불변식이 이루어지게 하라.

간단한 객체는 그냥 생성자를 사용해 만드는게 좋다.

다만 다른 클래스에 생성자 내에서 또다른 객체의 생성자를 호출하지 말아야 한다.

Solid 법칙의 원리를 잊지말고 지키면 도움이 된다.

리파지터리

프로그램에서 객체에 대한 참조는 어떻게 얻어올 수 있을까?.

프로그램에서 전역으로 찾아야할 객체는 사실 많지 않다. 나머지 잽합체에 속하는 객체들은 사실 직접 끄집어내어 조작할 일이 없기 때문이다.

집합체는 도메인 객체들의 일관성 단위이고, 리파지토리는 집합체를 영속화하고 조회할 수 있게 해주는 추상화 계층이다.

리파지토리는 팩토리를 사용하는 계층이 되기도 한다.

클라이언트가 팩토리로 객체를 만들어 리파지토리에 전달하는 패톤도 있다. 이건 사용자 인터페이스나 도메인 모델에 따라 틀려진다.

언어의 사용(확장예제)

3부 더 심층적인 통창력을 향항 리팩터링

초기 도메인모델을 더욱 개발하고 확장해나가기 위해서는 도메인 전문가와의 지속적인 커뮤니케이션과 개념확장 그리고 그에 따른 지속적인 리팩토링이 필요히다.

리팩토링이란 기능을 유지하면서 설계를 다시 하는걸 말한다. 리팩토링할때는 자동화 테스트가 있으면 좋다.

도메인주도 모델에서의 리팩토링은 도메인에 대한 새로운 통찰력이 이루기 위한 변경이나 좀더 개념을 분명이 하는걸 말한다.

지속적인 리팩토링을 하려면 설계 자체가 변경을 지원해야 한다. 이걸 유연한 설계라고 한다.

도약

리팩토링 효과는 선형적으로 증가하지 않는다 특정 시점에 도약한다.

코드가 조금씩 개선되다 보면 도메인을 개선시킬수 있는 통찰력이 서서히 열리게 된다.

도메인 설계에 큰 변화가 생기면 역시 코드도 크게 리팩터링해야한다. 하지만 그 과정은 고통스럽고 위험하다. 하지만 이 과정에 성공하면 큰 도약을 하게된다.

도약은 갑자기 나타나지 않는다. 단계적인 리팩토링을 거치고 나서야 도약이 나타난다.

너무 멀리 내다보려고 코드개선을 멈춰서는 안된다.

심층 모델이 한번의 도약을 거치고 나면 다른 중요한 개념들이 속속 나타나기 시작한다.

도약이 한번 일어나면 연속적으로 도약의 징후가 생긴다.

무조건 열심히 일하며 프로그램에 복잡성을 키워나가기 보다는. 리팩토링하며 재정비를 히야 모델의 더 깊은 아이디어가 표출되어 도약을 가져온다.

암시적인 개념을 명확하게

암시적인 개념을 명확하게 하는것도 도약을 가져오는 하나의 방법이다.

도메인 전문가와 자주 이야기를 나누다 보면 개념이 명확하게 되어 도약을을 가져온다.

모순에 대하 깊이 고민하는게 도약하는데 도움이 된다.

서적을 참고하라. 분명해 보이는 길이라고 할지라도 전문 서적을 참고하면 도움이 된다.

처음 아이디에어 집착하지 말고 새로운 모델을 시험하고 또 시험해라.

제약 조건도 개념을 명확하게

제약조건을 모델로 명시화해라. 그럼 설계가 대폭 좋아진다.

프로세스도 중요한 도메인 모델로 인정해라.

절차(프로세스)도 도메인 정책에 중요한 측면으로 인정해라. 모델 내에 프로세스를 표현해야 한다.

제약 조건과 프로세스를 명시화 하면 설계가 한결 명확해진다.

명세

명세는 제약조건의 논리를 결정한다.

명세는 도메인 설계의 일부분이며 도메인 계층에 속해야 한다. 응용계층에 속해서는 안된다.

명세는 자연스럽게 전략패턴과 함께 사용되곤 한다.

떠하누명세느느객체의ㅡ인터페이스 명세로 쓰이기도ㅠ한다. 이런 구조작인 명세로ㅠ사용될때는 서로ㅠ다른 두개의 컴포넌트를 병렬개발 가능해진다. 명세와 프로토타입으로 개발하고 점점 구현은 구체화 라며뉴되기 때문이다.

또한 명세는 객체의 인터페이스 명세로 쓰이기도 한다. 이런 구조적인 명세로 사용될때는 서로 다른 두개의 컴포넌트의 병렬개발이 가능해진다. 명세의 포로토타입을 개발하고, 구현은 차근차근이 구체화 하면 되기 때문이다.

유연한 설계

유연한설계는 리팩토링을 쉽게 만든다.

추상계층은 결합을 약하게 만들지만, 그것도 너무 과하면 오히려 유연한 설계에 방해가 된다.

의도를 드러내는 인터페이스

인터페이스가 없으면 코드를 이해하기 위해 내부 구현을 깊이 파고들 수밖에 없다. 그러면 인지 부하가 커지고 코드 이해가 훨씬 복잡해진다.

메서드 이름은 수행 방법 관점에서 짓지 말고, 결과와 목적을 기준으로 네이밍하는 것이 좋다.

부수효과가 없는 함수

부수효과를 통제하면 복잡성을 제어할 수 있다.

단언

테스트 단언을 추가해서 테스트로 코드의 목적을 암시하라.

개념적 윤곽

개념적 윤곽이란 쉽게 말해서 의미있는 기능의 단위를 찾아낸 것이다.

새로 발견되거나 알게된 개념을 코드에 적용하다 보면 개념적 윤곽이 들어나는데, 코드에 조화롭게 연결시키려면 리팩토링이 필요하다.

개념적 윤곽을 코드에 반영해 놓으면 코드가 더 이해하기 쉬워진다.

독립형 클래스

객체에 의존성이 많으면 코드가 복잡해지고 파악하기 어려워진다.

그래서 객체가 다른 객체를 직접 참조하지 못하도록 노력하는데, 낮은 결합도를 달성하기 위함이다.

독립형 클래스(standalone class)**란 상태를 갖지 않고, 도메인에 관련된 규칙·절차·계산 로직을 담은 객체 어떤 도메인 객체집합에도 속하지 않는, 독립된 객체(해결사 특수부대)

도메인 객체(엔티티나 밸류)에 속하지 않지만

도메인의 일반적인 규칙이나 복잡한 계산 로직을 처리하기 위해

별도로 추상화하여 분리해놓은 클래스를 말한다.

연산의 닫힘

DDD의 “연산의 닫힘”은 도메인 객체가 자기 자신의 의미 공간 안에서만 조합되고 변화하도록 만드는 함수형적 닫힘성이다.

즉, 도메인 모델을 하나의 펑터처럼 다루는 것과 같다.

이런식으로 객체를 보호하면 연산의 결과가 예측 가능해지므로 복잡성이 제어된다.

선언적으로 만들어라

선언적 특성을 활용하여 코드 자체가 무엇을 하는 코드인지 의도가 나타나게 하라.

하위 도메인으로 나눠라.

하위도메인에 이미 증명된 모델을 사용해라.

분석 패턴의 적용

재사용 가능한 객체모델을 분석 패턴이라고 한다. 이미 증명된 패턴의 모델을 재사용하는 것이다.

기본에 경험했던 패턴을 참고하여 패턴을 적용해라.

모델과 디자인패턴의 연결

디자인 패턴중 일부는 도메인 패턴으로도 사용할 수 있다.

특히 컴포니트 패턴과 전략패턴은 도메인 설계에 적용하면 편리히다.

전략패턴

설명생략

컴포지트 패턴

설명생략

flyweight 패턴

일반적으로 공통적으로 사용되는 상태는 한번만 만들어 놓고 여러 객체에서 참조하도록 함.

더 심층적인 통찰력을 향한 리팩토링

코드를 소규모로 반복해서 리팩토링함으로써 도메인의 개념을 더 명확히 드러내고, 그 심층적 통찰을 모델에 반영하라.

즉, 구현 → 관찰 → 리팩토링 → 더 좋은 모델 → 반복.

모든 리팩토링에 동일한 비용을 들이지 말고, 핵심(비즈니스 가치 높은) 부분에 투자해라.

4. 전략적 설계

모놀리식 대규모 모델이나. 여러 하위모델이 복합된 모델에서 복잡성을 다루는 전략.

모놀리식 구조나 여러 하위 모델이 복합된 복잡한 모델 속에서 도메인의 본질적 복잡성을 다루기 위해 디스틸레이션(distillation) 과정이 필요하다.

이 과정은 전체 모델 중 **핵심이 되는 부분(Core Domain)**을 부각시키고,

나머지 영역은 보조(Subdomain)나 일반(Generic) 영역으로 구분하여 모델을 정제(정리)하는 것이다.

이를 통해 각 Bounded Context가 명확히 구분되고 중요한 부분에 개발 역량을 집중할 수 있게 된다.

모델의 무결성 유지

여러 팀, 여러 모델, 여러 시스템이 협력해도 각 모델의 의미가 깨지지 않고 유지되게 만드는 것.

한마디로 연관된 모델간 경계를 명확히해서 독립성을 지키게 하는것.

제한된 컨텍스트(경계 설정)

모델이 유지될 수 있는 최소한의 독립된 영역이 있어야한다.

사실은 다른 도메인이지만 비슷한 유형의 도메인의 언어나 언어는 언뜻보면 비슷해보인다.

하지만 허위동족언어인 경우가 많으므로 주의해야한다.

지속적인 통합

**지속적 통합(Continuous Integration)**은 여러 공동 작업자들이 도메인 모델을 공유하며 개발할 때, 모델 간 의미적 차이가 생기지 않도록 지속적으로 병합하고 조율하는 활동을 말한다.

이는 단순히 코드 수준의 병합만을 뜻하지 않고, **모델의 개념적 통합(Model-level Integration)**까지 포함한다.

비록 모델과 구현은 기술적으로 구분될 수 있지만, 도메인 주도 설계에서는 모델과 구현이 하나의 유기적 체계로 움직이기 때문에 모델적 통합과 구현 통합은 사실상 동일한 의미를 갖는다.

컨텍스트맵

Context Map은 여러 Bounded Context(모델 경계) 간의 관계, 의존 방향, 통합 방식, 그리고 팀 간 협업 방식을 명시적으로 표현하는 설계 지도이다.

공유커널

앜잘수 없는 경우는 도메인모델간 공유 영역으루정하고 유지하라. 그게ㅜ공유커널이다.

그리고 공유커널은 더ㅜ잦은 주기로 통합하라.

고객 개발 팀 / 공급자 개발 팀

라이버르러 공급팀과 그걸 이용해 서비스를 만드는 팀간의 관계를 예로 들 수 있다.

이런 경우 개발을 원활하게 하는 방법론은 이미 있다. 그게 반복계획 프로세스라고 하는것이다.

(고객과 공급자의 입장에서 주기적으로 커뮤니케이션을 하는 것이다)

conformist(준수자)

하류팀이 상류팀의 도메인 룰을 따르는 방법.

오류 방지 계층(anticorruption layer)

외부 시스템 또는 다른 모델 계층(Bounded Context)의 모델이 우리 도메인 모델을 오염시키지 않도록 막는 보호 계층. 개념적으로는 번역기 역할 계층을 말한다.

오류 방지 계층은 코드상에 존재할 수도 있고, 단지 개념적 방어선으로만 존재할 수도 있다.

중요한 건 “존재 형태”가 아니라 “도메인 오염을 방지하는 역할”을 수행하느냐다.

separate ways

두 컨텍스트의 중복 부분을 통합하려는 비용이, 각자 따로 가는 비용보다 더 클 때!

두 도메인이 비슷해 보여도 서로 영향을 주지 않게 완전히 분리해서 개발하는 것이다.

이 방법은 모델, 코드, 데이터, 팀, 배포 모두 독립적으로 운영한다.

공개 호스트 서비스

공개 호스트 서비스(Open Host Service) = “다른 컨텍스트가 우리 시스템과 연동할 수 있도록 공식적이고 안정적인 API(서비스 인터페이스) 를 제공하는 전략.”

published language

Published Language = “서로 다른 컨텍스트가 통신할 때 쓰는 공식 언어 계약서.”

내부 도메인 언어가 아니라, 경계 밖에서 합의된 공용어야.

디스틸레이션

여러 개념 중에서 핵심 개념(Core Domain)을 부각하고, 덜 중요한 부분(Generic Subdomain, Supporting Subdomain)을 분리해내는 일

도메인 비전 선언문

도메인 비전 선언문은 모델의 나침반이자, 팀 전체가 같은 ‘언어적 방향성’을 유지하게 해주는 문장이다.

처음부터 “우리가 이 도메인에서 진짜로 풀고 싶은 문제는 무엇인가?”를 짧고 명확한 문장으로 선언하는 것이다.

응집력있는 매커니즘

도메인 모델의 수많은 계산식들에서도 응집력 있는 매커니즘을 발견할수 있다.

너무 많은 메서드들이나 계산식은 도메인의 방향성을 잘 안보이게 만든다. 이런 상태에서는 응집력있는 매커니즘을 뽑아내 분리시킬수만 있다면 도메인의 목표가 더 분명하게 드러나게 된다.

분리된 핵심

Segregated Core는 핵심 도메인 내에서 가장 중요한 부분을 모듈 수준으로 재분리하여, 그 중요성에 걸맞게 보호하고 집중하기 위한 전략적인 분리이다.

추상화된 핵심

'Abstract Core’는 코어 도메인에서 핵심적인 부분을 추상화하여 인터페이스타 추상화모듈로 분리해내는 것이다. 이런 추상화된 핵심은 일종의 문서 역할을 한다.

대규모 구조

대부분의 대규모 시스템 구조는 UML로 표현되지 않으며, 그렇게 할 필요도 없다.

발전하는 질서

아케텍처는 앱이 발전함에 따라 변하는 것이다. 초기 설계 때문에 앱의 발전에 제한이 걸려서는 안된다.

시스템 은유

시스템 은유는 시스템 전체 또는 시스템의 주요 부분을 쉽게 이해하고 시각화할 수 있는 비유적인 이미지나 개념으로 표현하는 것을 말한다.

이 은유는 팀의 모든 구성원 (도메인 전문가, 개발자, 테스터)이 시스템의 본질과 구조를 공통적으로 이해하고 논의할 수 있는 기반을 제공한다.

단순히 예쁜 단어를 고르는 것을 경고하며, 은유가 실제 시스템의 본질적인 작동 방식과 구조를 정확히 반영해야 한다고 강조.

책임계층

대규모 모델에서는 자연적으로 층이 나뉘어지게 되는데, 이건 책임계층을 나눠야하는 신호다.

인위적으로 층을 나누어 구분하면 대규모서비스를 이해하는데 도움이 된다.

탈착식 컴포넌트 프레임워크

이 패턴은 사실상 DDD의 핵심인 **‘핵심 도메인(Core Domain)을 보호하기 위해 외부의 모든 것을 추상화된 인터페이스를 통해 분리하는 전략’**을 대규모 시스템 구조에 적용한 결과.

탈착식 컴포넌트 프레임워크란, 각 구성요소가 독립적이고 교체 가능하게 설계된 시스템 구조로, 테스트 주도 개발을 통해 자연스럽게 형성되는 유연한 아키텍처다.

전략의 총합

프레임워크를 고를때는 고급 커스터마이징이 가능한 고급사용자를 위한걸 고르고 초보들을 위한 간단한 프레임워크는 피할것.

재능있는 팀원이 아닌 가장 똑똑한 전문가를 아키텍처팀에 둘것. 등등