DDD

비즈니스 문제우리가 개발하는 소프트웨어는 비즈니스 문제의 솔루션이다.효과적인 소프트웨어 솔루션을 설계하려면 적어도 기본적인 비즈니스 도메인 지식이 있어야 함. → 도메인 전문가의 몫효과적인 소프트웨어는 도메인 전문가가 문제를 생각하는 방식을 모방해야 함. → 이해가 없

비즈니스 도메인이란?회사가 고객에게 제공하는 서비스ex) 스타벅스는 커피로 가장 잘 알려져 있다.ex) 월마트는 가장 널리 알려진 소매업체 중 하나이다.하위 도메인이란?비즈니스 활동의 세분화된 영역고객에게 제공하는 서비스 단위로 비즈니스 도메인을 만든다.스타벅스는 커피

모델들의 경계 → 유비쿼터스 언어의 일관성이 유지되는 경계유비쿼터스 언어를 여러 개의 작은 언어로 나눈 다음 명시적으로 할당함.모델은 실제 세계의 복사본이 아닌 복잡한 시스템을 이해하는 데 도움을 주기 위해 구조화 한 것이다.경계가 없다면 현실 세계의 복제본과 같이 확

Bounded Conext의 모델은 서로 독립적으로 발전하고 구현될 수 있다. 하지만 그 자체는 독립적이지 못한다. → 시스템 요소가 독립적으로 구성될 수 없듯이 상호작용 해야만한다.Contract: Bounded Context 사이에 있는 접점협력형, 사용자-제공자형

모든 비즈니스 하위 도메인을 동일하게 만들지는 않는다. 각각 전략적 중요성과 복잡한 정도가 다르다. 그래서 비즈니스 로직 코드를 모델링하고 구현하는 다양한 방법이 있다. 비교적 단순한 비즈니스 로직에 적합한 두 가지 패턴인 트랜잭션 스크립트와 액티브 레코드가 있다.

앞장에서는 비교적 간단한 비즈니스 로직을 다루는 두 가지 패턴에 대해 논의했다. 이번 장에서는 계속해서 비즈니스 로직의 구현에 대해 다루는데, 복잡한 비즈니스 로직에 사용되는 도메인 모델 패턴이 있다.

도메인 모델 패턴은 복잡한 비즈니스 로직을 갖는 핵심 하위 도메인에서 적용된다. 이벤트 소싱 도메인 모델 패턴은 도메인 모델과 동일한 전술적 패턴(VO, Aggregate, Domain Event)을 사용한다. 하지만 이 두 가지 구현 패턴은 Aggregate의 상태를

아키텍처 패턴은 코드베이스의 다양한 측면에 대한 구성 원칙을 도입하고 이들 사이의 명확한 경계를 제시한다. 예를 들어 비즈니스 로직이 어떻게 시스템의 입출력, 그리고 다른 기반의 구성요소와 연결되는가와 같은 것이 코드베이스의 다양한 측면 중 하나다. 단기적으로는 비즈니

단일 컴포넌트 경계를 넘어 시스템 요소 전반의 커뮤니케이션 흐름을 구성하는 패턴에 대해 알아 보고자 한다. 이번 페이지에서 소개할 패턴은 바운디드 컨텍스트 간 커뮤니케이션을 용이하게 하고, Aggregate 설계 원칙에 의해 부과된 제한 사항을 해결하고, 여러 시스템

다양한 소프트웨어 설계 의사결정, 즉 도메인 주도 설계를 돕는 분석도구를 사용하는 휴리스틱에 대해 알아 보고자 한다.