본문 바로가기

DDD88

DDD 요약 목차 참고서적DDD 개요전략설계 - Domain - Ubiquitous Language - Bounded Context - Context Map - Domain Event 전술설계 - Architecture - Domain Event, EDA - Aggregate - Entity - Value Object - Factory - Repository - Service - Module - Application Event Storming 2024. 11. 27.

DDD와 SI 프로젝트 공정 그리고 MSA 2024. 9. 10.

[Aggregate] 규칙 : 결과적 일관성 규칙: 경계의 밖에선 결과적 일관성을 사용하라 애그리게잇을 아우르는 규칙이 언제나 최신 상태로 유지되길 기대할 순 없다. 이벤트 처리, 배치 처리, 그 밖의 업데이트 메커니즘을 통해 지정된 시간 내에서 의존성이 해결될 수 있도록 할 수 있다. Evans, 128쪽］ 따라서 하나의 애그리게잇 인스턴스에서 커맨드를 수행할 때 하나 이상의 애그리게잇에서 추가적인 비즈니스 규칙이 수행돼야 한다면 결과적 일관성을 사용하자. 한 인스턴스를 수정할 경우에 그와 관련된 다른 수정이 완료될 때까지 어느 정도 의 시간 지연을 용납할 수 있는지 도메인 전문가에 게 물어보자. 도메인 전문가는 지연된 일관성의 개념에 대해 때론 개발자보다 훨씬 더 관대할 수도 있다. 그들은 비즈니스 내에서 항상 발생하는 현실적 지연 상황에 관.. 2024. 9. 6.

[Aggregate] 규칙 : ID로 다른 애그리게잇을 참조하라 규칙: ID로 다른 애그리게잇을 참조하라 애그리게잇이 다른 애그리게잇 루트로의 참조를 가질 수 있다 참조하는 애그리게잇(Backlogitem)과 참조된 애그리게잇(Product)을 같은 트 랜잭션 안에서 수정해선 안 된다. 하나의 트랜잭션에선 둘 중 한쪽만 수정해 야한다 하나의 트랜잭션에서 여러 인스턴스를 수정하고 있다면 일관성 경계가 잘못 됐다는 신호일 가능성이 높다. - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p464~465 2024. 9. 6.

[Aggregate] 규칙 : 작은 애그리게잇 규칙: 작은 애그리게잇으로 설계하라 이제 큰 클러스터의 애그리게잇을 유지하는 데 드는 추가적인 비용이 무엇인지 면밀히 살펴볼 준비가 됐다. 모든 트랙잭션이 성공한다고 보장되더라도, 큰 클러스터에는 여전히 성능과 확장성의 문제가 있다. ... 성능과 확장성은 무시할 수 없는 비기능적 요구사항이다. 작은 애그리게잇을 설계할 때 ‘작다’는 단어는 어떤 수준을 의미할까? 극단적인 예로 전역 고유 식별자와 추가 특성 하나를 갖고 있는 애그리게잇을 생각해볼 수 있을 텐데, 이는 권장하지 않는 형태다.차라리 애그리게잇을 루트 엔터티와 최소한의 특성이나 값 타입의 속성으로 제한하자.정확히 필요한 만큼만 담고, 그 이상도 이하도 아니어야 한다. ... 크기가 작은 애그리게잇은 성능과 확장성이 더 좋을 뿐 아니라, 커밋을.. 2024. 9. 3.

[Aggregate] 규칙 : 일관성 경계 규칙: 진짜 고정자를 일관성 경계 안에 모델링하라 바운디드 컨텍스트(2)에서 애그리게잇을 찾으려면 모델의 진짜 고정자(Invariant)를 이해해야 한다. 이를 알아야만 주어진 애그리게잇으로 묶어야 할 객체가 무엇인지 결정할 수 있다. 고정자(Invariant)는 언제나 일관성을 유지해야만 한다는 비즈니스 규칙이다. 일관성에는 여러 종류가 있다. 그중 한 가지는 트랜잭션적 일관성 consistency인데, 이는 즉 각적이고 원자적이라 간주된다. 또 한 가지로 결과적 일관성 eventual consistency이 있다. 고정자에 관한 논의는 트랜잭션적 일관성과 관련이 있다. 일관성 경계는 어떤 오퍼레이션이 수행되든 상관없이 경계 안의 모든 대상이 특정 비즈니스 고정자 규칙 집합을 준수하도록 논리적으로.. 2024. 9. 3.

[Aggregate] Aggregate의 어려움 처음에는 신중을 기해서 일관성의 경계를 통해 엔터티(5)와 값 객체(6)를 애그리게잇으로 묶는 일이 쉬워 보일 수 있지만, 애그리게잇은 모든 DDD의 전술적인 지침 중에서도 무엇보다 정확히 규명되지 않은 패턴 중 하나다. 애그리게잇을 잘못 모델링하는 방식에는 여러 가지가 있다.컴포지션의 편의에 맞춰 설계하다 보면 애그리게잇을 너무 크게 만들어버리는 함정에 빠질 수 있다.이 현상의 반대 편에는 애그리게잇을 모두 걷어내는 바람에 결과적으로 진정한 고정자를 보호하지 못하는 경우도 있다. 앞으로 보게 되겠지만, 양극단의 경우를 모두 피하면서 비즈니스 규칙에 주의를 기울여야 한다. - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p449~450 2024. 9. 2.

[Domain Event] 지연 시간 허용 (비동기, 결과적 일관성) 메시지를 수신할 때 오래 소요될 수도 있는 지연 시간 (결과적 일관성까지 수 밀리초 이 상의 지연이 나타날 때) 이 문제를 유발하진 않을까? 분명히 이는 신중히 고려해야 하는 문제이며, 동기화되지 않은 데이터가 잘못된 영향을 미치거나 동작을 망가뜨리기도 한다. 상태의 일관성을 달성하기 위해 얼마나 긴 시간을 허용할지, 감당할 수 없는 한계는 어디인지를 질문해봐야 한다. 도메인 전문가라면 허용 가능한 지연과 가능하지 않은 지연의 기준에 대해 거의 같은 의견을 갖고 있다. (개발자가 생각하는 실시간 보다 훨씬 관대할수도 있다)상태의 일관성을 달성하기까지 초나 분이나 시간 단위를 비롯해서 심지어는 하루가 넘는 기간도 허용 가능할 수 있다는 점은 대부분의 개발자에게 놀라움으로 다가온다. 그렇다고 이런 이.. 2024. 9. 2.

[Domain Event] Messaging을 이용한 독립성(자치성) 다른 시스템을 호출하는 대신에 비동기적 메시징을 사용해 시스템 사이에서 높은 수준의 독립성(자치성 autonomy)을 달성하자. (REST API로 직접 호출하지 말고, Domain Event를 사용하자. 그래야 API에 종속되지 않고 독립성/자치성이 좋아진다) 엔터프라이즈를 둘러싼 바운디드 컨텍스트로부터 도메인 이벤트를 전달해주는 메시지를 수신하면, 바운디드 컨텍스트 안의 모델에서 해당 이벤트의 의미를 반영하고 있는 행동을 실행하자. 이는 다른 비즈니스 서비스에서 여러분의 비즈니스 서비스로 단순히 데이터를 복제하거나 객체의 정확한 복사본을 만들라는 의미가 아니다. 실제로 일부 데이터는 시스템 사이에서 복사될 수 있다. 적어도 복사된 데이터는 외부 애그리게잇의 고유 식별자를 포함하게 된다. 그렇지만 한.. 2024. 9. 2.

[Domain Event] MQ, 결과적 일관성 세상에는 사용할 수 있는 수많은 메시징 컴포넌트가 존재하고, 일반적으로 이는 미들웨어로 분류된다. 액티브MQ ActiveMQ, 래빗MQ RabbitMQ, 아카 Akka, N서비스버스 NServiceBus, 매스트랜짓 MassTransit 등과 같은 오프소스에서부터 상용 라이선스 제품까지 수많은 옵션이 있다. ...바운디드 컨텍스트 사이에서 사용하는 모든 메시징 메커니즘을 사용하기 위해선 결과적 일관성을 달성하려는 의지가 필요하다. 이는 포기할 수 없는 부분이다. 하나 이상의 다른 모델이 변경되도록 영향을 미치는 어떤 모델의 변경은 일정 시간이 흐르기 전에는 완전한 일관성을 달성하지 못한다. 더 중요한 점은, 개별 시스템으로의 트래픽과 해당 시스템이 다른 시스템에 미치는 영향에 따라 시스템 전체가 완전.. 2024. 9. 2.

[Domain Event] Event Modeling .. 이벤트를 모델링할 땐 해당 이벤트가 속한 바운디드 컨텍스트의 유비쿼터스 언어에 따라 이벤트와 그 속성을 명명하자. 애그리게잇의 커맨드 오퍼레이션 실행에 따른 결과로서 이벤트가 발생한다면, 그 이름은 보통 실행된 커맨드로부터 파생된다. 커맨드는 이벤트의 원인이므로, 이벤트의 이름을 통해 과거에 발생한 커맨드도 적절히 나타낼 수 있다. 예제 시나리오에 따르면, 우리가 백로그 항목을 스프린트로 커밋할 때 도메인에 일어난 일을 명시적으로 모델링하는 이벤트를 발행한다. 커맨드 오퍼레이션 : BacklogItem.commitTo (Sprint aSprint) -> 이벤트 결과 : BacklogltemCommitted ‘백로그 항목이 커밋됐다.’는 의미의 이벤트 이름은 요청된 오퍼레이션이 성공한 후 애그리게.. 2024. 9. 2.

[Domain Event] Batch Job과 Domain Event ..시스템이 배치 처리를 수행하는 평범한 상황을 생각해보자. * 아마 시스템은 사용량이 적은 시간대 (아마 밤 시간대) 에 어떤 종류의 일일 유지 관리를 처리할 텐데, * 불필요한 객체를 지우고 새롭게 형성된 비즈니스 상황을 지원하는데 필요한 것들을 생성하고, 일부 객체를 다른 객체와 일치시키고, (데이터를 일괄 생성, 수정, 삭제 등의 작업) * 심지어 어떤 사용자에겐 중요한 일이 일어났음을 알려주기까지 한다. (처리 결과를 이메일, SMS 등으로 알림) * 종종 이런 배치 처리의 수행에선 일부 복잡한 쿼리를 수행해 비즈니스 상황에 주목해야 할지 결정하는 일도 필요하다.* 이를 처리하는 계산과 과정에는 큰 비용이 소모되고 모든 변경을 동기화하는 데는 많은 트랜잭션이 필요하다. 만약 이 성가신 .. 2024. 9. 2.

[Domain Event] Domain Event 정의, 특징 ..도메인에서 발생한 사건을 포착하기 위해 도메인 이벤트를 사용하자. 이벤트는 아주 강력한 모델링 도구다. 일단 도메인 이벤트를 사용하는 법을 알고 나면, 여러분은 이에 중독돼서 어떻게 여지껏 도메인 이벤트 없이 살아왔는지 의아해질 것이다. 도메인에서 일어난 어떤 사건을 나타낸다. 도메인에서 발생한 어떤 일이 도메인 전문가에게 중요한지 어떻게 결정할수 있을까? 전문가들과 논의를 통해 그들이 알려주는 단서에 귀를 기울여야 한다. (이러한 단서를 어떤 방법으로 파악할 수 있을까? PPT, 엑셀 등의 문서? 산출물?Event Storming 과 같이 다함께 공유/집중할 수 있는 Workshop이 효과적이지 않을까?)도메인 전문가가 다음과 같은 말을 던질 때 집중하자. “...할 때” “그런 일이 일어나면.... 2024. 9. 2.

Entity ..개발자는 도메인보다 데이터에 초점을 맞추려는 경향이 있다. 소프트웨어 개발에 관한 대부분의 접근법이 데이터베이스에 중점을 두기 때문에, DDD를 처음 접하 는 사람에게 일어날 수 있는 현상이다. 풍부한 행동(Operation)을 바탕으로 도메인 개념을 설계 design 하진 않고, 주로 데이터의 속성(열)과 연결(외래 키)을 먼저 생각하려 한다. 이렇게 해서 데이터 모델을 대응하는 객체로 투영하게 되는데, 이로 인해 ‘도메인 모델’ 안에 있는 거의 모든 개념이게터와 세터 메소드를 너무 많이 갖고 있는 엔터티로 코딩된다. 우리를 위해 이런 요소를 생성해주는 도구는 손쉽게 찾을 수 있다. 속성 접근자 가 잘못된 건 아니지만, 이것이 DDD 엔터티가 수행해야 하는 행동의 전부는 아니다. 엔.. 2024. 8. 30.

EDA (Event Driven Architecture) ..이벤트 주도 아키텍처 （EDA, Event Driven Architecture）는 이벤트의 생산, 감지, 소비와 이벤트에 따른 응답 등을 촉진하는 소프트웨어 아키텍처다. [Wikipedia, EDA] 이 육각형이 들어오고 나가는 이벤트에는 여러 종류가 있을 수 있는데, 우린 도메인 이벤트에 특히 관심이 있다. 이 애플리케이션은 시스템이나 엔터프라이즈나 다른 타입의 이벤트도 마찬가지로 구독할 수 있다. 아마 이런 다른 이벤트는 시스템의 상태, 모니터링, 로깅, 동적 프로비저닝 등의 문제를 다룰 것이다. 그러나 모델링에 주의를 요하는 사건을 전하는 것은 도메인 이벤트다.(쇼핑몰이라면 주문, 주문취소, 교환, 반품, 배송 등이 주요 도메인 이벤트다)우리는 엔터프라이즈에서 이벤트 주도 방식의 시스템을 지원하.. 2024. 8. 30.

CQRS ..사용자가 필요로 하는 데이터 뷰를 리파지토리로 쿼리하기란 어려울 수 있다. 특히 사용자 경험 설계가 여러 애그리게잇 타입과 인스턴스로부터 데이터 뷰를 생성해야 할 때가 어렵다. 여러분의 도메인이 정교할수록 이런 상황이 발생할 가능성이 높아진다. (말이 어렵게 표현되어 있는데, 여러 DB 또는 여러 Table 또는 여러 System에 흩어진 데이터를 한번에 조회(쿼리)하기 어려운 경우가 있다는 말이다) 도메인 데이터를 뷰에 매핑하는 완전히 다른 방법이 있을까? 이 질문에 대한 대답으로, 이상한 이름을 가진 아키텍처 패턴인 커맨드-쿼리 책임 분리 (CQRS : Command-Query Responsibility Segregation) 가 있다. 이 아키텍처는 엄격한 객체（또는 컴포넌트）의 설계 원.. 2024. 8. 30.

왜 REST를 사용하는가 REST 원리에 맞게 설계된 시스템은 느슨한 결합의 조건을 충족한다. ...보다 작은 단위(리소스)로 나눠지며, 각 단위가 개별적으로 테스트 및 디버깅할 수 있고, 사용 가능한 진입 지점을 노출하기 때문에 REST 기반 시스템은 이해하기가 훨씬 쉽다. ...레스트풀 HTTP는 느슨하게 결합돼야 하고 높은 확장성이 필요한 아키텍처에게 훌륭한 선택이 될 수 있다. - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p205~206 2024. 8. 21.

Bounded Context간의 Relationship * 파트너십 Partnership두 가지 컨텍스트 안의 팀이 성공이나 실패를 함께한다면 협업관계가 나타나야 한다. 이 팀들은 개발과 통합의 공동 관리를 위한 잘 조정된 기획 과정을 도입한다. 팀들은 양측 시스템 모두의 개발 요구를 수용할 수 있는 인터페이스를 만들어 나가기 위해 반드시 협력해야 한다. 상호의존적인 기능은 반드시 일정을 세워 같은 릴리스에서 완성할 수 있도록 해야 한다.* 공유 커널 Shared Kernel모델에서 공유된 부분과 이에 관련된 코드는 아주 가까운 상호의존성을 형성하는데, 이는 설계 작업을 도울 수도 있고 약화시킬 수도 있다.도메인 모델에서 팀이 공유하기로 동의한 부분집합 일부를 명시적 경계로 지정하자.커널(핵심)은 작게 유지하자. 이 명시적 공유는 특별한 상태에 놓이며, 다른.. 2024. 8. 13.

Context Map 현재 프로젝트 상황의 시각적 컨텍스트 맵 당신의 프로젝트와 관련된 바운디드 컨텍스트와, 그 사이의 통합관계를 컨텍스트 맵으로 그리자 컨텍스트 맵은 여러분이 상호 교류해야 하는 시스템의 목록을 제공할 뿐만 아니라, 팀 내부의 의 사소통에서도 촉매 역할을 한다. - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p148~149 .. 컨텍스트 맵은 기존의 지형을 포착한다. 우선은 현재를 매핑해야 한다. 상상의 미래를 그려선 안 된다. 만약 현재 프로젝트가 진행함에 따라 지형이 변한다면, 그 시점에서 맵을 업데이트하면 된다. 먼저 여러분이 어디에 있는지 이해할 수 있도록 현재상황에 집중하고, 그 이후에 어디로 향할지 정하자. 시각적인 컨텍스트 맵을 만드는 일.. 2024. 8. 13.

Bounded Contex와 개발팀 ..단일 바운디드 컨텍스트에는 단일 팀 하나의 바운디드 컨텍스트에 하나의 팀이 일하도록 (one service per team 와 유사한 개념) 하나의 잘 정의되고 응집력 있는 도메인 전문가와 개발자의 팀이 명시적인 바운디드 컨텍스트 안에서 모델링된 하나의 유비쿼터스 언어에 집중하는 편이 가장 최선이라는 의미다. 만약 둘 이상의 구분된 팀을 하나의 바운디드 컨텍스트 안에 배치할 경우, 각 팀은 상이 하고 잘못 정의된 유비쿼터스 언어를 만들게 된다. - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p131 .. 위의 상황을 그림으로 표현하면 다음과 같다 2024. 8. 12.

Bounded Context의 크기, Microservice의 크기 .. DDD를 사용한 도메인 모델의 주요 구성 요소인 모듈, 애그리게잇, 이벤트, 서비스는 하나의 바운디드 컨텍스트 안에 어느 정도의 수가 포함돼야 할까? (이는 Microservice의 크기가 어느정도여야 하는가? 에 대한 물음과 동일하다) 이는 “줄 하나의 길이는 얼마나 되나요?”라고 묻는 것과 다를 바가 없다. 바운디드 컨텍스트는 완전한 유비쿼터스 언어를 표현하기 위해 필요한 크기만큼 커야 한다.(덩그러니 줄 하나만 두고 이게 긴가요 짧은가요 라고 묻는것과 같다.어떤 Context에서 사용되는지를 알아야 답할수 있다예를들면 매듭을 묶기에는 이정도면 적당할 수 있지만 큰 배를 묶기에는 턱없이 부족할 것이다마찬가지로 테이블 10개, 기능 5개 정도의 서비스가 적당합니까라고 묻는것과 마찬가지다10개 .. 2024. 8. 12.

Bounded Context 와 DB .. (Bounded Context의 도메인 모델) 모델이 영속성 데이터베이스 스키마의 생성을 주도할 때 데이터베이스 스키마는 경계의 안쪽에 위치한다.이는 모델링 (개발팀) 팀이 스키마를 설계하고 개발해서 유지하기 때문에 그렇다. 즉 데이터베이스 테이블 이름과 열 이름은 다른 스타일로 변환된 이름이 아니라 모델에 사용된 이름 그대로를 반영한다. (아래 코드 참고)반대로, 만약 데이터베이스 스키마가 이미 존재하거나 데이터 베이스 모델러로 만들어진 별도의 팀이 데이터베이스 스키마의 설계에 반대한다면, 스키마는 도메인 모델이 차지한 바운디드 컨텍스트 안쪽에 머무르지 못한다. (Owner 개발팀이 관리하는 Bounded Context 내 DB가 위치해야 하고그 DB는 Owner팀이 Control할 수 있어야한다.. 2024. 8. 12.

동일한 용어가 여러 컨텍스트에 사용되는 예 : 출판사의 책 같은 도메인에서 동일한 용어가 여러 바운디드 컨텍스트에 걸쳐 쓰이는 경우 책의 수명주기 life cycle 가 다양한 단계로 나뉘어 나타나는 상황에서 출판 조직이 다뤄야 하는 모델링의 어려움을 생각해 보자. 책이 이와 같은 여러 컨텍스트를 거치며 진행되는 상황처럼 출판사도 이와 비슷한 단계를 따라서 처리하게 된다. * 책을 개념화하고 제안함 * 저자와 계약 * 책의 저작권 및 편집 프로세스 관리 * 그림 등 책의 레이아웃 디자인 * 다른 언어로 책을 번역 * 실제 인쇄/전자책 출간 * 마케팅 * 대리점과 소비자에게 직접 책을 판매 * 대리점과 소비자들에게 실제 책을 배송 각 단계마다 책을 모델링하는 올바른 방법이 단 한 가지뿐인가? 절대 그렇지 않다. 각 단계마다 책은 다른 정의를 가진다. 책은.. 2024. 8. 12.

Bounded Context 란 ..도메인 모델이 존재하는 명시적 경계 이 경계 안에선 모든 유비쿼터스 언어의 용어와 구문이 구체적인 의미를 갖게 됨 바운디드 컨텍스트는 주로 언어적 경계 - 명시적으로 다른 두 모델 내부에선 같거나 비슷한 이름의 객체임에도 서로 다른 의미를 갖는 경우가 종종 있다 - 두 모델을 각자의 명시적인 경계로 둘러싸면, 각 컨텍스트 안의 각 개념이 나타내는 의미가 확실해진다 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p119~120 ..각 바운디드 컨텍스트의 언어는 모든 모델이 순수하게 유지될 수 있도록 존중받아야 한다. 언어적 분리와 엄격한 준수는 프로젝트에 관련된 각 팀이 자신만의 고유한 바운디드 컨텍스트에 집중하도록 해주고, 자신의 비전을 자신의 .. 2024. 8. 12.

Sub Domain(Problem Space)와 Bounded Context(Solution Space) sub domain(s) = problem space = 논리적 공간/영역solution space = bounded context(s) = 물리적 경계 도메인은 문제점 공간 problem space과 해결책 공간 solution space을 모두 갖고 있다 problem space - 우리에게 풀어야 할 전략적 비즈니스 문제점을 생각하게 하고 - 핵심 도메인과 핵심 도메인이 사용하는 서브도메인의 조합 solution space - 비즈니스 문제점을 풀어줄 소프트웨어를 구현하는 방법에 초점 - 하나 이상의 바운디드 컨텍스트 - 구체적인 소프트웨어 모델의 집합 - 바운디드 컨텍스트는 특화된 해결책이자 실제 구현을 비추는 창이기 때문 - 바운디드 컨텍스트는 해결책을 소프트웨어로 실현시키는 데 활용 서브도메.. 2024. 8. 12.

Sub Domain 종류 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p107 도메인 -> 서브 도메인서브 도메인의 종류 : 핵심, 지원, 범용 핵심도메인 - 그 조직의 성공에 가장 중요한 비즈니스 도메인의 한 부분 - 전략적 측면에서 비즈니스는 핵심 도메인에서 탁월함을 보여줘야 - 비즈니스의 성공을 지속시키기 위해 가장 중요한 부분 - 해당 프로젝트에는 가장 높은 우선 순위가 부여 - 서브도메인에 깊은 지식을 가진 한 명 이상의 전문가와 최고의 개발자는 물론이고, ... 가능한 한 많은 재량과 영향력을 줘야 - DDD 프로젝트에 투입되는 노력의 대부분은 핵심 도메인에 초점 - 핵심 도메인의 구현에는 탁월함이 요구되는데, 그 이유는 핵심 도메인이 비즈니스에 분명.. 2024. 8. 9.

쇼핑몰에서의 고객이 모두 동일한 고객인가 전자상거래 시스템 안에 적어도 네 개의 서브도메인이 있다는 점을 고려해보면, 용어와 의미가 충돌하리라는 점이 거의 확실하다. 예를 들면, 고객이라는 용어는 분명 다수의 의미를 지닌다. 사용자가 카탈로그를 살필 때의 고객과 주문을 할 때의 고객은 서로 다른 의미다. 그 이유는 다음과 같다. 카탈로그를 살필 때의 고객은 이전의 구매, 충성도, 가능한 제품, 할인, 배송 옵션이라는 컨텍스트에서 사용된다. 그러나 주문 시의 고객은 제한된 의미를 갖는다. 세부사항 몇 가지를 살펴보자면 배송지 주소, 청구지 주소, 총 금액, 지불 방법 등이 있다. 이런 기본적인 이유만으로도 전자상거래 시스템 안에선 고객의 의미가 분명치 않아진다. - Implementing Domain-Driven Design 도메인 주도 설계 .. 2024. 8. 9.

Bounded Context와 언어적 경계 ..DDD를 도입하면서, 도메인 모델에서 사용된 모든 용어의 의미가 잘 이해되도록 각 바운디드 컨텍스트를 잘 나누려고 노력한다. 또는 우리가 소프트웨어의 모델링을 잘 수행했다면 당연히 이해할 수 있을 정도가 되도록 노력한다. 이는 주로 언어적 경계이며, 이런 컨텍스트상의 경계는 DDD 구현의 중요 요소다. - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p104.. 2024. 8. 9.

Sub Domain과 Bounded Context 예 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p101 전자상거래의 바운디드 컨텍스트 안에는 비록 분명하게 구분되진 않지만 여러 내재된 도메인 모델이 있다. 분리될 수 있었다면 좋았을 도메인 모델이 사실상 하나의 소프트웨어 모델로 뭉쳐 있으며, 이는 매우 안타까운 일이다. 이 소매업체가 직접 구축하지 않고 써드파티에게 이 바운디드 컨텍스트를 구매했다면 문제가 덜했겠지만, 이 시스템을 누가 관리하든 제품 카탈로그, 주문, 송장, 배송 모델 등을 하나의 큰 전자상거래로 엮음에 따라 복잡도가 높아지며 부정적인 결과를 초래했다. 새로운 기능을 추가하기 위해 다양한 논리적 모델이 더욱 커져감에 따라, 대립되는 관심사 때문에 진행에 방해를 받는다. .. 2024. 8. 9.

Domain, Sub-Domain 그리고 Monlith, Microservice ..도메인 모델이라는 용어도 도메인이라는 단어가 들어있으므로, 한 조직의 전체 비즈니스 도메인（엔터프라이즈 모델 같은）을 위한, 하나로 응집력 있게 모든 항목을 포함하는 모델을 만들어야겠다고 생각할 수도 있다. 그러나 DDD를 사용할 때의 목표는 그게 아니다. DDD에서 강조하는 부분은 오히려 그 반대다. 그 조직의 전체 도메인은 여러 서브도메인으로 이뤄져 있다. DDD를 사용할 때 모델은 바운디드 컨텍스트 안에 만들어진다. 사실, 도메인 모델의 개발은 전체 비즈니스 도메인에서 단 하나의 특정 분야에 집중할 수 있는 한 방법이다. 적당히 복잡한 조직을 하나의 모든 것을 포괄하는 모델로 정의하려는 노력은 극도로 어려운 정도면 다행이고, 대개는 성공하기 힘들다. 이 장에서 명확하게 다루겠지만.. 2024. 8. 6.

이전 1 2 3 다음

티스토리툴바