Architecture

정의 Domain-Driven Design(DDD)은 도메인의 프로세스와 규칙을 풍부하게 담은 도메인 모델을 프로그래밍하는 데 개발의 중심을 두는 소프트웨어 개발 접근법이다. 2003년 Eric Evans의 책 Domain-Driven Design: Tackling Complexity in the Heart of Software에서 이름이 유래했다. Evans 본인은 DDD를 세 가지로 요약한다. Core Domain에 집중한다. 도메인 전문가와 소프트웨어 전문가의 창의적 협업으로 모델을 탐구한다. 명시적으로 경계 지어진 컨텍스트 안에서 하나의 보편 언어를 사용한다. Martin Fowler는 Evans의 기여를 “모델링 표기법 논쟁을 넘어서는 어휘를 만든 것"으로 평가한다. 도메인 모델이 중요하다는 주장 자체는 1980~90년대 데이터 모델링과 객체지향 분석에서도 있었지만, Evans는 그 접근을 이야기할 수 있는 용어 체계(Entity, Value Object, Aggregate, Bounded Context 등)를 정리했다. ...

정의 Bounded Context는 특정 모델이 정의되고 적용되는 경계에 대한 기술이다. 보통 하나의 하위 시스템이거나 특정 팀의 작업 범위에 대응한다. Fowler는 이를 “DDD 전략적 설계의 중심 패턴"이라고 부른다. DDD가 큰 모델을 다루는 방식은 그것을 여러 Bounded Context로 나누고, 그 사이의 관계를 명시적으로 밝히는 것이다. 동작 원리 큰 프로젝트에는 항상 여러 모델이 존재한다 Evans가 제시하는 근거는 세 가지다. 두 하위 시스템이 서로 다른 사용자 집단을 대상으로 하고, 하는 일이 달라서 서로 다른 모델이 유용한 경우가 흔하다 독립적으로 일하는 팀들은 소통 부족으로 같은 문제를 다른 방식으로 해결한다 도구 자체가 달라서 코드를 공유할 수 없는 경우도 있다 여러 모델이 존재하는 것은 불가피하다. 문제는 서로 다른 모델에 기반한 코드가 합쳐질 때 생긴다. 소프트웨어에 버그가 생기고, 신뢰할 수 없게 되고, 이해하기 어려워진다. 팀원 간 소통도 혼란스러워진다. 어떤 컨텍스트에서 모델을 적용하면 안 되는지가 불분명해지기 때문이다. ...

개요 Bounded Context를 정의하는 것만으로는 부족하다. 전체를 보는 시야가 없으면 다음 문제가 남는다. 다른 모델의 컨텍스트가 여전히 모호하고 계속 변한다 다른 팀 사람들은 컨텍스트 경계를 잘 모르므로, 모르는 채로 경계를 흐리거나 연결을 복잡하게 만드는 변경을 한다 경계가 분명해도, 다른 컨텍스트와의 관계가 모델의 성격이나 변경 속도에 제약을 건다. 이 제약은 주로 비기술적 경로로 나타나기 때문에 그것이 영향을 주는 설계 결정과 연결짓기 어렵다 Context Map은 이 관계들을 명시적으로 그리는 작업이다. 그리는 방법 Evans의 처방은 다음과 같다. ...