Chapter 2: 바운디드 컨텍스트 및 보편언어와 전략적 설계

💡 책에서 기억하고 싶은 내용

DDD는 바운디드 컨텍스트 내에서 보편언어 를 모델링하는 것에 대한 것이다

바운디드 컨텍스트

• 바운디드 컨텍스트 는 의미적으로 동일한 컨텍스트의 범위를 표현한다

  • 그 범주 내에서 소프트웨어 모델의 각 컴포넌트는 특정한 의미를 갖고, 특정한 일을 수행한다는 의미다

  • 바운디드 컨텍스트 컨텍스트 내에 존재하는 컴포넌트들은 컨텍스트에 특화되어 있으며, 컨텍스트 안에서 의미가 살아난다

• 바운디드 컨텍스트 는 모델이 구현 되는 곳이고, 바운디드 컨텍스트마다 각각 분리된 소프트웨어 산출물이 나온다

  • 각각의 바운디드 컨텍스트는 단일 팀 에만 할당되어야 하고, 각 바운디드 컨텍스트마다 독립적인 소스 코드 레파지토리 가 있어야 한다

    • 한 팀은 다수의 바운디드 컨텍스트에 대해 일을 할 수 있지만, 다수의 팀이 하나의 바운디드 컨텍스트를 수행할 수는 없다

  • 보편언어를 나눈 것과 같은 방법으로, 바운디드 컨텍스트마다 Source code와 DB Schema도 명확히 분리한다

  • 하나의 바운디드 컨텍스트를 한 팀이 수행한다는 것은 특히 중요한데, 이는 다른 팀이 소스 코드를 변경할 때 문제가 발생할 가능성을 완전히 제거할 수 있기 때문이다

    • 각 팀은 각자의 소스 코드와 데이터베이스를 소유하고, 공식 인터페이스를 정의 해서 바운디드 컨텍스트를 다른 팀이 사용할 수 있게 허용 한다

      • 이것이 DDD 사용의 이점이다!

• DDD는 서로 다른 개념들을 각기 다른 바운디드 컨텍스트 안으로 분리해 놓음으로써 개념간 차이 를 더욱 중시한다

  • 각기 다른 언어와 그에 따른 기능이 존재하는 것을 인정하는 것이다

• 바운디드 컨텍스트는 한 덩어리로 뭉쳐 있지 않기 때문에 테스트를 하나의 모델에 집중할 수 있다

  • 테스트 양이 적어지고, 더 빨리 테스트를 수행할 수 있다는 장점이 있다

보편언어

• 바운디드 컨텍스 안에서 사용되는 언어는 팀 구성원들이 이야기 할 때 사용되고, 소프트웨어 모델 안에 구현되기 때문에 보편언어 라고 부른다

• 보편언어 는 엄격하고, 정확하고, 엄중하며, 단호해야 한다

• 팀의 누군가가 보편언어 표현을 사용하면, 팀 모두가 그 표현이 가진 제약사항과 정확한 의미를 이해한다

  • 그 표현은 개발되고 있는 소프트웨어 모델을 정의하는 모든 언어처럼 팀 내에서 보편적이기 때문이다

핵심 도메인

• 바운디드 컨텍스트가 조직의 핵심 전략적 계획으로 개발되고 있을 때, 이를 핵심 도메인 이라고 한다

• 핵심 도메인은 가치 있는 것들을 달성하는 수단 이 되기 때문에 가장 중요한 소프트웨어 모델 중 하나다

• 무엇이 핵심도메인 이어야 하고, 어떤 것을 제외시켜야 하는지 현명하게 선택해야 한다

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

• 바운디드 컨텍스트는 전략적 계획 의 핵심이 되는 모든 개념들을 밀접하게 유지하면서 표용해야하고, 나머지는 모두 제외 시켜야 한다

  • 엄격하게 핵심만 걸러낸 후 살아남은 개념들은 해당 바운디드 컨텍스트를 소유하는 팀의 보편언어 일부가 된다

    • 경계는 그 엄격함을 강조한다

• 필수적인 두 가지 그룹 (도메인 전문가 와 소프트웨어 개발자 )을 하나로 묶어 서로 협업하는 팀을 만들어야 한다

  • 도메인 전문가

    • 도메인 전문가 는 당연히 비즈니스 문제에 좀 더 집중할 것이다

      • 그들의 생각은 비즈니스가 동작하는 방법에 대한 비전에 의미를 둔다

    • 도메인 전문가 는 다양한 비즈니스 영역들마다 존재한다

      • 이것은 직책이 아니라, 비즈니스에 중점을 두는 사람들 을 의미한다

    • 팀의 보편언어의 토대는 비즈니스를 바탕으로 한 도메인 전문가들의 멘탈 모델이다

  • 개발자

    • 개발자는 소프트웨어 개발에 중점을 둔다

    • DDD 프로젝트를 수행하는 개발자는 핵심 전략 목표의 비즈니스 초점을 받아들이지 못하는 기술 중심의 주장 을 하지 않도록 조심해야 한다

      • 즉, 개발자는 근거 없는 간결성 은 피하고, 해당 팀의 바운디드 컨텍스트 안에 팀이 점진적으로 개발하는 보편언어를 수용할 수 있어야 한다

• DDD를 사용하는 이유는 비즈니스 모델의 복잡도가 높기 때문 이다

  • 그렇다고 해서 모델이 가지는 복잡도 이상으로 복잡한 모델을 만들 이유는 없다

  • 프로젝트의 기술적 축면 보다 비즈니스 모델 이 더 복잡하기 때문에 DDD를 사용한다

  • 이것이 바로 개발자가 도메인 전문가 와 함께 비즈니스 모델을 파고들어야 하는 이유다!

• 개발자와 도메인 전문가 모두 문서로만 소통하는 상황을 피해야 한다

  • 최고의 보편언어는 서로 협업하며 나오는 거듭된 피드백 에 의해 만들어지며, 이 과정에서 팀의 화합된 멘탈 모델 을 만들 수 있다

보편언어 개발하기

• 핵심 도메인 을 명사에만 제한시킬 필요가 없다

  • 핵심 도메인이 도메인 모델에 나타난 개념에 대한 구체적인 시나리오들을 나타낼 수 있게 만들어야 한다

• 거듭해서 모델을 개선할 방법을 찾는 것 이 필요하다

• 코드가 모델이고, 모델이 코드다

• 시나리오 안의 개념에 이름을 붙이거나 구별할 수 있는 정체성을 부여하는 것이 도움이 될 때만, 별도의 이름과 구분짓는 특성을 부여하자

아키텍처

• 포트와 어댑터 아키텍처 다이어그램을 보면, 바운디드 컨텍스트가 도메인 모델 이상의 다양한 요소들 로 구성되는 것을 확인할 수 있다

  • 이런 레이어들은 거의 모든 바운디드 컨텍스트 내에 존재한다

    • Input Adapter

      • 사용자 인터페이스 컨트롤러

      • REST endpoints

      • Message listener

    • Application Service

      • Use case를 조율하고 트랜잭션을 관리한다

    • Domain Model

      • 우리가 중점을 두는 도메인 모델

    • Output Adapter

      • 영속성 관리(Persistence management)

      • Message sender

• 포트와 어댑터 는 초기 아키텍처에서도 사용할 수 있지만, 이들이 DDD와 함께 사용할 수 있는 고유한 것은 아니다

  • 필요하다면 포트와 어댑터뿐만 아니라 다른 아키텍처나 아키텍처 패턴 도 목적에 따라 조합해서 사용할 수 있다

    • Event Driven Architecture

    • CQRS: Command Query Responsibility Segregation

    • 반응 및 액터 모델

    • REST: Representational State Transfer

    • 서비스 지향 아키텍처 (SOA)

Chapter 2 요약

• 너무 많은 것을 하나의 모델에 넣는 것과 큰 진흙 덩어리 를 만드는 것과 관련된 몇가지 중요한 위험 요소들

• DDD 전략적 설계의 적용

• 바운디드 컨텍스트와 보편언어의 사용

• 가정들에 대한 분석과 멘탈 모델 을 통합하는 방법

• 보편언어 를 개발하는 방법

• 바운디드 컨텍스트 내에서 발견할 수 있는 아키텍처 컴포넌트

• DDD를 실행 방안에 넣는 것이 전혀 어려운 일이 아니라는 것!