[DDD] 1. 도메인 주도 설계 이해

목차

1. 본질적 복잡성

2. 도메인 주도 설계

3. 도메인 주도 설계 주의

 

 

1. 클린 아키텍처

비즈니스 규칙이 Java, Javascript, SQL 등에 분산되어 있고 심지어 기획자가 알고있는 비즈니스 규칙이 코드가 아닌 문서에만 운영 정책으로 작성되어 있다면 유지보수가 어려워지고 요구사항이 추가될 때마다 시스템의 복잡도는 점점 높아질 것이다.

예) 소수점 표현 정책이 Java, Javascript, SQL 에서 모두 다르다.

클린 아키텍처를 적용해 비즈니스 규칙을 한 곳에 모을 수 있다.

 

 

클린 아키텍처

클린 아키텍처는 계층을 분리하여 관심사를 분리하고 의존성 규칙을 통해 아키텍처가 동작하도록 한다.

 

의존성 규칙: 모든 소스코드 의존성은 반드시 외부에서 내부로, 고수준 정책을 향해야 한다.

즉, 업무의 업무 로직을 담당하는 코드들이 DB 또는 Web 같이 구체적인 세부 사항에 의존하지 않아야 한다.

이를 통해 업무 로직(고수준 정책)은 세부 사항들(저수준 정책)의 변경에 영향을 받지 않도록 할 수 있다.

출처: The Clean Architecture, https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

클린 아키텍처는 로버트 C. 마틴이 제안한 좋은 소프트웨어 아키텍처의 보편적인 원칙으로 다음과 같은 특징을 가지고 있다.

프레임워크 독립성	아키텍처는 다양한 기능의 라이브러리를 제공하는 소프트웨어, 즉 프레임워크의 존재 여부에 의존하지 않는다. 이를 통해 이러한 프레임워크를 도구로 사용할 수 있으며, 프레임워크가 지닌 제약사항 안으로 시스템을 욱여 넣도록 강제하지 않는다.
테스트 용이성	업무 규칙은 UI, 데이터베이스, 웹 서버, 또는 여타 외부 요소가 없이도 테스트할 수 있다.
UI 독립성	시스템의 나머지 부분을 변경하지 않고도 UI를 쉽게 변경할 수 있다. 예를 들어 업무 규칙을 변경하지 않은 채 웹 UI를 콘솔 UI로 대체할 수 있다.
데이터베이스 독립성	오라클이나 MS SQL 서버를 몽고DB, 빅테이블, 카우치DB 등으로 교체할 수 있다. 업무 규칙은 데이터베이스에 결합되지 않는다.
모든 외부 에이전시에 대한 독립성	실제로 업무 규칙은 외부 세계와의 인터페이스에 대해 전혀 알지 못한다.

 

본질적 복잡성(essential complexity)과 우발적 복잡성(accidental complexity)

본질적 복잡성은 문제 자체에서 발생하며 문제의 범위를 줄이지 않고는 제거할 수 없다. 

반면에 우발적 복잡성은 솔루션으로 인해 발생하며 프레임워크, 데이터베이스 또는 기타 인프라가 될 수 있다.

 

클린 아키텍처와 같은 개념으로 좋은 소프트웨어 아키텍처의 보편적인 원칙을 지키고 고수준인 규칙을 캡슐화하였다면 

도메인 주도 설계는 본질적 복잡성을 낮추는 방법에 초점을 맞춰 시스템의 복잡성을 낮출수 있도록 한다.

 

---

 

2. 도메인 주도 설계

도메인

도메인은 소프트웨어로 해결하고자 하는 문제 영역이다.

쇼핑몰을 구축할 때 도메인은 전자 상거래이며, 사용자가 무엇에 대해 말하고 원하는지 이해하려면 전자 상거래에 대한 지식이 필요하다.

 

도메인 모델

도메인 모델은 특정 다이어그램이 아니라 다이어그램이 전달하려는 아이디어이자 목적을 가진 의사소통 수단이다. 이 의사소통 수단은 회의, 기획, 디자인, 개발에 사용되어야 한다.

 

항공권 예약 시스템에서는 항공기, 승객 등 물리적으로 존재하는 것들을 모델링할 수 있고, 회계 시스템에서는 화폐, 금융 등 물리적으로 존재하지 않는 것들을 모델링할 수 있다. 도메인 모델을 사용하면 여러 이해관계자가 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는 데 도움이 된다.

 

도메인 주도 설계

기획자가 생각하는 도메인 모델과 개발자가 생각하는 도메인 모델은 대부분 다르다.

개발자는 요구 사항을 기술 언어로 번역하고 솔루션에 집중해 문제를 숨기는 경향이 있다.

번역된 언어는 의사소통을 위해 언어를 다시 번역해야 하고 이 과정에서 많은 의사소통 비용이 낭비된다.

 

도메인 주도 설계는 도메인 모델의 적용 범위를 구현으로 확장하기 위해 도메인을 탐색하고 학습하기 위한 다양한 원칙과 패턴을 제안한다.

 

• 유비쿼터스 언어
• 전략적 설계
• 전술적 설계

 

3. 도메인 주도 설계 주의

• 경우에 따라 DDD 기술 규칙과 패턴이 DDD 구현에 방해가 될 수 있다.
• 중요한 것은 패턴 자체가 아니라 비즈니스 문제에 맞게 코드를 구성하고 동일한 비즈니스 용어(유비쿼터스 언어)를사용하는 것이다.
• CRUD 서비스처럼 간단한 업무는 DDD가 아닌 더 간단한 방법으로 관리할 수 있다.
• 도메인 주도 설계는 완벽히 설계하고 그 다음 구현하는 방법을 의미하지 않는다. 설계와 구현을 병행하도록 한다.

 

 

 

 

 

 

출처

NEXTSTEP: DDD 세레나데 3기