[도메인 주도 설계 핵심] 2장 바운디드 컨텍스트 및 보편언어와 전략적 설계

14 Mar 2020

Bounded Context

• 의미적으로 동일한 컨텍스트의 범위를 표현한다.

Bounded Context, 팀, Source Code Repository

• Bounded context는 단일 팀에만 할당돼야 한다.
  • 다른 팀이 소스 코드를 변경할 때 문제가 발생할 수 있다.
• Bounded Context마다
  • 독립적인 Source Code Repository가 있어야 한다.
  • 데이터베이스 스키마도 명확히 분리한다.
• 공식 인터페이스를 정의해서 Bounded Context를 다른 팀이 사용할 수 있게 한다.

진흙 덩어리

• 시스템의 경계 없이 여러 개의 뒤엉킨 모델을 담고 있다.

도메인 전문가와 비즈니스 동인

비즈니스 동인

• 비즈니스 전문가

비즈니스 전문가의 이야기에 귀를 기울여야 한다.

각 사업 부서들의 정책은 각기 다른 이유로 존재한다.

• 사업 부서는 세 곳인데 세 가지 정책 모두를 하나의 정책으로 통합하려 한다면, 분명 문제가 발생할 것이다.
• DDD는 서로 다른 개념들을 각기 다른 바운디드 컨텍스트 안으로 분리한다.

사례 연구

스크럼 기반 애자일 프로젝트 관리 애플리케이션이 핵심 개념에서 진흙 덩어리가 되어 가는 과정

핵심 개념

• Product
  • Backlog Item
    • Task
  • Release
  • Sprint

사용자도 필요해요!!

• Tenant(관련된 조직)
  • User
    • Permission

또 다른 협업 도구들도 필요해요!!

• Forum
  • Post
• Calendar

테넌트들이 지불할 수 있는 방법도 제공해야 해요.

• Account
  • Payment
  • SupportPlan

기본적인 전략적 설계를 하려면

전략적 설계 도구

• Bounded Context
  • Bounded Context를 사용하는 것은 “핵심이 무엇인가?”라는 질문에 답하도록 유도한다.
  • 전략적 계획의 핵심이 되는 모든 개념들을 밀접하게 유지하면서 포용해야 하고, 나머지는 모두 제외시켜야 한다.
• Ubiquitous Language
  • Bounded Context에 남은 개념들은 팀이 사용하는 Ubiquitous Language의 일부가 된다.

핵심이 무엇인지 어떻게 알 수 있을까?

• 도메인 전문가와 소프트웨어 개발자를 하나로 묶어 협업하는 팀을 만들어야 한다.
• 도메인 전문가
  • 비즈니스에 중점을 둔다.
• 개발자
  • 소프트웨어 개발에 중점을 둔다.
  • 비즈니스 초점을 받아들이지 못하는 기술 중심의 주장을 하지 않도록 조심해야 한다.
  • 근거없는 간결성은 피한다.
  • 팀의 Bounded Context 안에 보편언어를 수용할 수 있어야 한다.
• 문서가 대화를 지배하는 상황은 피한다
  • 열려있는 대화, 탐구 => 핵심 도메인에 대한 깊은 통찰
  • 협업하며 나오는 피드백에 의해 최고의 Ubiquitous Language가 나온다.

도전과 통합

스크럼 기반 애자일 프로젝트 관리 애플리케이션을 바꿔보자.

핵심이 무엇인가?

• 핵심은 스크럼이다.
• Tenant, User, Permission이 스크럼과 관련이 있는가?
  • 이들 개념은 스크럼 소프트웨어 모델에서 제외해야 한다.
  • Team, ProductOwner, TeamMember로 대체한다.
• SupportPlans, Payment는 스크럼 프로젝트의 일부일까?
  • 아니다.
  • 이들은 Context 밖에 있다.
• 핵심 도메인에 제외시켰던 개념들은
  • 각각의 Bounded Context 내에 정의되어야 한다.
  • Context Mapping 을 통해 Bounded Context 들을 통합한다.

보편언어 개발하기

Ubiquitous Language

• 도메인 모델에 나타난 개념 및 구체적인 동작을 표현해야 한다.

작업에 시나리오 넣기

시나리오

• 컴포넌트가 동작하는 방식
• 제품 책임자는 스프린트에 백로그 아이템을 할당한다. 백로그 아이템은 이미 릴리스에 예정돼 있고, 팀원의 정족수가 작업을 승인한 경우에 한해 할당한다. 만일, 이미 다른 스프린트에 할당됐다면, 이를 먼저 해제한다. 할당이 완료되면, 할당이 어디서 해제됐고, 현재 어디에 할당됐 있는지 알린다.

작성된 시나리오를 팀의 명세서와 비교해 어떻게 도메인 모델을 검증하는 데 사용할 산출물로 전환할까?

• 인수 테스트를 만든다.
• 단위 테스트 프레임워크를 사용할 수도 있다.