도메인 주도 설계란 무엇인가?(Domain Driven Design Quickly) 를 읽고서

최근에서야 DDD, 즉 도메인 주도 설계라는 개념이 있다는 것을 알게 되었다. 아직 객체 지향 설계도 제대로 못 다루는데 도메인 주도 설계에 대해서 공부하는 게 맞는 건가라는 생각이 들지만 보통 지금까지의 공부했던 방식을 생각해보면 이해하지 못했더라도 다른 걸 공부하다 보면 결국에는 공통된 부분이 언급되고 그거에 대해서 학습하다 보면 갑자기 이해가 되는 경우가 있다는 걸 알기에 오늘도 묵묵히 학습을 정리해 본다.  (해당 책은 회사 팀장님이 빌려주셨다. 간단하게 도메인 주도 설계에 대해서 알고 가라고 빌려주신 거 같은데 생각보다는 잘 읽히지 않았다.)

 

 소프트웨어는 현실 세계의 프로세스를 자동화하거나 비즈니스 문제를 해결하기 위해 개발된다.

자동화된 비즈니스 프로세스나 현실 세계의 문제가 소프트웨어의 도메인이다. 우선 소프트웨어란 이 도메인으로부터 시작되고 떼려야 뗄 수 없는 관계를 가지고 있을을 반드시 이해해야 한다. 소프트웨어 프로젝트를 시작할 때, 우리는 그 소프트웨어가 동작해야 하는 도메인에 집중해야 한다.

 

도메인 주도 설계란 무엇인가?

 

도메인이란 무엇인가? 하나의 도메인은 세상의 어떤 것이다. 

추상화란 무엇인가? 그것은 도메인을 표현한 모델이다.

모델은 소프트웨어 설계에서 필수적인 부분이다. 복잡성을 다루려면 모델이 필요하다.

 

소프트웨어 전문가와 도메인 전문가들은, 도메인 모델을 함께 만들어 낸다. 따라서 이 모델은 두 전문 영역이 만나는 장소가 된다. 소프트웨어의 목적이란 현실 세계의 도메인 안에 있는 비즈니스 문제들을 해결하기 위한 것이기 때문이다. 따라서 그 도메인과 소프트웨어는 철저하게 혼합되어야만 한다.

 

유비쿼터스 언어

 

도메인 주도 설계의 핵심 원칙은 모델 기반의 언어를 사용하는 것이다. 모델은 소프트웨어와 도메인이 서로 교차하는 지점이기 때문에 모델 기반 언어를 사용하는 것이 가장 적절하다. 

소프트웨어 아키텍트, 개발자, 도메인 저문가로 구성된 설계팀은 자신들의 행동을 통합하고, 모델 작성과 작성된 모델의 코드화를 도와줄 언어가 필요하다는 점이다.

 

모델 주도 설계

 

계층형 아키텍처

• 사용자 인터페이스 : 사용자에게 정보를 보여주고 사용자의 명령을 해석하는 책임을 진다.
• 애플리케이션 레이어 : 애플리케이션 활동을 조율하는 얇은 레이어다. 업무 로직을 포함하지 않는다. 비즈니스 객체의 상태를 보관하지 않지만, 애플리케이션 작업의 처리 상태는 보관한다.
• 도메인 레이어 : 도메인 정보를 포함한다. 업무 소프트웨어의 심장에 해당한다. 비즈니스 객체의 상태를 포함한다. 비즈니스 객체와 이 객체의 상태 정보중 가능한 부분의 영속성에 대한 책임은 인프라스트럭처 레이어로 위임한다.
• 인프라스트럭처 레이어 : 다른 레이어 모두를 지원하는 라이브러리로 동작한다. 레이어 간의 통신을 제공하고 비즈니스 객체의 영속성을 구현하고 사용자 인터페이스 레이어의 라이브러리를 포함한다.

• 엔티티 : 고유한 식별자를 가진 객체 
• 값 객체 : 식별이 아니라 해당 속성에 초점이 맞추어진 객체 (값이 동일하다면 구분할 수 없다. 사실상 구분의 의미 없음)
• 서비스 : 서비스 객체는 내부에 상태를 가지지 않으면서, 단순히 도메인에 기능을 제공한다.
• 모듈 : 관련된 개념과 작업을 조직화하여 복잡도를 감소시키는 기법
• 집합 : 집합은 데이터를 변경할 때 하나의 단위로 간주되는 관련된 객체들의 집합
• 팩토리 :  객체 생성에 필요한 지식을 캡슐화하는데 사용되며 집합을 생성하는데 특히 유용하다.
• 리파지토리 : 인프라 스트럭처와 객체가 직접 관련되지 않도록 한다. 이미 존재하는 객체를 복원한다.

 

깊은 통찰을 향한 리펙터링

 

리펙터링은 애플리케이션의 기능에 변화를 주지 않고 코드를 더 좋게 만들기 위해 재설계하는 절차이다. 결국 리펙터링의 목적은 코드를 나쁘지 않게, 다시 말해 더 낫게 만드는 것이다. 

정교한 도메인 모델이란, 도메인 전문가와 이 도메인에 대해 관심 있는 개발자들이 밀접하게 엮인 조직이 반복적으로 리팩터링을 수행하지 않으면 만들어질 수 없다.

 

모델 무결성 보존

 

대규모 공동 작업에서 모델의 무결성은 어떻게 유지되어야 하는가? 이를 달성하기 위해서 필요한 개념들에 대해서 알아보자.

 

분할된 컨텍스트 - 하나의 모델은 하나의 팀에 할당하기에 적합할 만큼 작아야 한다.

지속적인 통합 - 분할된 컨텍스트 안에서 단일한 모델로의 지속적인 통합은 필수적으로 필요하다.

컨텍스트 맵 - 서로 다른 분할된 컨텍스트들과 그들의 관계에 대한 개요를 표현한 문서다.

공유 커널

고객-공급자 - 하나의 프로젝트 내의 두 서브시스템 한쪽이 다른 한쪽에 완전히 의존하는 식의 특별한 관계를 맺는 경우

순응 - 변경을 가할 수 없는 공급자의 모델에 전적으로 의지하는 방향

변질 방지 레이어 - 두 개의 서로 다른 도메인과 언어 간에 양방향 번역자의 역할을 한다. 가장 큰 장점은 클라이언트 모델이 외부로부터 영향받는 오염 없이 순수하고 일관된 상태로 남는다는 점이다.

분할 방식 - 통합의 가치가 파생되는 문제점 보다 작을 때 우리는 분할 방식으로 가야 한다. 분할 방식 패턴은 기업 애플리케이션을 몇 개의 작은 애플리케이션으로 쪼개어 만들고자 할 때 사용된다.

오픈 호스트 서비스

증류 - 핵심 도메인을 찾아내고, 지원 모델이나 코드의 혼란스러운 덩어리 속에서 핵심 도메인을 쉽게 구분할 수 있는 수단도 제공하라. 가장 가치 있고 특화된 개념을 강조하고 핵심을 작게 유지하라.

 

오늘날 DDD는 중요하다.

 

왜 DDD가 오늘날 더욱 중요하다고 생각하십니까?

 기본적으로 DDD는, 사용자들이 밀접하게 관계되어 있는 도메인 이슈에 집중해야 한다는 원칙을 기반에 둡니다. 도메인이란 우리가 이해하기 위해 혼신의 힘을 다해야만 하는 가장 중요한 부분이고, 전문가들에게는 개념적 형태로 표현해 내기 위해 힘써서 협동해야 할 대상이며, 동시에 힘 있고 유연한 소프트웨어를 만들 수 있도록 해주는 부분이기 때문입니다.

 

도메인 모델링의 위험을 늘 기억하세요

1. 단순한 상태를 유지하세요. 모델러도 코드를 작성해야 합니다.

2. 구체적인 시나리오에 초점을 맞추세요. 추상적 생각은 실제 사례에 연결되어 있어야만 합니다.

3. DDD를 모든 것에 적용하려고 하지 마세요. 컨텍스트 맵을 그리고 어느 부분에 DDD를 적용하고 어느 부분에 하지 않을지 결정하세요. 그리고 경계 바깥에 있는 것들에 대해서는 신경 쓰지 마세요.

4. 실험을 많이 하고 실수를 많이 할 것이라고 예상하세요. 모델링은 창조적인 작업입니다.

 

 

읽고 나서

 

책을 읽고 관련 내용을 찾아보면서 이제야 도메인 주도 개발에 대한 감을 잡고 있는 과정이다. 책의 내용을 완벽하게 이해하는 것을 목표로 두지 않았다. 그저 나오는 단어를 조금씩 익히고 써보는 정도로 가볍게 접근하였다. 시작에 불과하지만 이제야 도메인 주도 개발에 대해서 본격적으로 공부할 준비가 된 거 같다. 다음 책도 도메인 주도 개발에 대한 책이 될 예정이다. 조금 더 가보도록 하자.