> For the complete documentation index, see [llms.txt](https://chloe-codes1.gitbook.io/book-reviews/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://chloe-codes1.gitbook.io/book-reviews/ddd-distilled/02_-_-_-_-_-_.md).

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

<br>

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

<br>

> 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를 실행 방안에 넣는 것이 전혀 어려운 일이 아니라는 것!


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://chloe-codes1.gitbook.io/book-reviews/ddd-distilled/02_-_-_-_-_-_.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.