1. 도메인 주도 설계
Domain-Driven Design (DDD)로, 도메인 관점에서 설계하는 패턴이다. 확장성을 고려해 비즈니스 로직을 도메인 별로 나누어 설계하고, 모듈간의 의존성은 최소화, 응집성은 최대화하기 위한 방식이다. 이 방식은 소프트웨어의 복잡성을 최소화하는 것을 목적으로 하고, 새로운 비즈니스 요구사항에 대해 빠르게 반영할 수 있도록 소프트웨어 확장성을 제공한다. 역할 및 책임 분리로 인해 코드가 간결해지고 비즈니스 로직이 도메인 별로 명확하게 분리되므로, 객체지향적인 방식이다.
2. 데이터 중심 vs 도메인 중심
주로 우리는 데이터 중심의 개발이 익숙하다. 데이터 중심 개발에서는 ERD를 먼저 설계하고, 데이터 간 관계를 기반으로 도메인을 정의한 후, 패키지 구조를 테이블 중심으로 구성하는 경우가 많다. 각 도메인 패키지 아래에 엔티티를 구현하게 되며, ORM 기술을 사용한다고 하면 ERD 설계 시 설정한 외래키 관계에 따라 객체 간의 연관 관계를 설정한다. 트랜잭션 스크립트 패턴을 적용해 Service 클래스에 도메인 CRUD와 비즈니스 로직을 작성하며, 다른 도메인의 로직이 필요할 시 필요한 의존성을 주입받아 사용하게 된다.
많이 쓰이는 방식이지만, 비즈니스의 요구사항이 확장되면 데이터 구조부터 다시 정의해야 해서 복잡성이 증가되는 단점이 있다. 도메인 중심 설계는 비즈니스 확장 시 복잡성을 줄이고자 도메인을 중심으로 설계하는 것을 의미한다. 데이터 관계로 도메인을 결정하는 방식이 아니라 비즈니스를 중심으로 도메인을 설정한다.
3. 도메인 주도 설계 관련 개념
바운디드 컨텍스트
바운디드 컨텍스트는 큰 시스템을 여러 개의 작은 컨텍스트로 나누어 각 컨텍스트 내에서 특정한 비즈니스 규칙과 데이터 모델이 적용되는 것을 의미한다. 각 컨텍스트는 독립적으로 설계되고 구현되며, 서로 다른 컨텍스트는 인터페이스를 통해 상호작용한다.
바운디드 컨텍스트는 도메인 안에서 특정한 비즈니스 문제 영역을 나타내며 그 영역 안에서 용어, 개념, 규칙 등이 일관되게 적용된다. 도메인 모델링 시 전체 도메인을 작은 단위로 분리하여 각 바운디드 컨텍스트를 식별하고, 각 컨텍스트가 독립적으로 동작하도록 설계한다.
애그리거트
애그리거트는 도메인 모델에서 논리적으로 하나의 단위로 묶이는 객체들의 집합이다. 애그리거트 내부에는 여러 객체가 있을 수 있지만, 그중 애그리거트를 대표하는 객체를 애그리거트 루트라고 한다.
애그리거트 루트는 애그리거트의 유일한 진입점이다. 외부에서 애그리거트 내부의 객체에 접근하려고 하면 애그리거트 루트를 반드시 통해야 하며, 이러한 애그리거트 루트가 필요한 이유는 다음과 같다.
- 애그리거트 루트를 단일 진입점으로 관리해 애그리거트 내부 객체들와 연관된 데이터의 일관성을 유지한다.
- 변경 가능한 데이터의 범위를 애그리거트로 제한하여 트랜잭션을 효과적으로 제어하고, 성능과 안정성을 높인다.
- 도메인 모델을 명확하게 함으로써 복잡한 객체 연관 관계를 쉽게 관리할 수 있고, 유지보수가 용이해진다.
- 엔티티 객체 간 직접 참조를 방지해 시스템 결합도를 낮추고 시스템을 유연하게 한다.
- 데이터 저장소(Repository)를 통해 애그리거트 단위로 데이터를 저장하고 조회함으로써 데이터의 무결성을 보장한다.
4. 도메인 관점으로 설계하기
- 도메인 모델을 그려본다.
- 대표 도메인과 하위 도메인을 붙여 도메인 개념 모델을 그려본다.
- 개념 모델을 구현 모델(클래스)로 바꿔본다. 대표 도메인과 하위 도메인 사이에 연관관계를 정의해본다.
- 바운디드 컨텍스트를 설정한다. MSA 적용 시 바운디드 컨텍스트 단위로 서버를 분리하고, 도메인간 참조는 Rest 통신이나 Event를 활용한다.
5. DDD가 적합한 상황
도메인 주도 설계는 실무에서 자주 쓰인다. 그러나 모든 프로젝트에 적합한 것은 아니다. 2번에서 언급한 트랜잭션 스크립트 패턴을 사용하는 단순한 CRUD 기반의 프로젝트나 빠르게 MVP를 만들어야 하는 경우, DDD보다는 데이터 중심 설계 방식이 나은 선택이 될 수 있다.
그러나, 은행과 같이 복잡한 비즈니스 로직을 수행하는 대규모 금융 시스템이나 장기적으로 유지보수가 필요한 프로젝트의 경우엔 도메인 주도 설계와 도메인 모델 패턴을 함께 사용해 도메인들의 경계를 명확히 하고 시스템의 복잡성을 줄일 수 있다.
6. DDD 프로젝트 패키지 구조
Presentation
사용자의 요청을 해석하고 응답을 책임지는 계층이다.
Application
비즈니스 로직이 작성되는 곳으로, Service 클래스를 이 패키지에 작성한다. 트랜잭션을 관리하며, 모듈 간 연계해야 할 때 관련 로직을 작성한다. 중요한 점은, 데이터를 변경해야 할 경우 그 로직은 Domain 계층의 Repository 클래스 등으로 위임해야 한다.
Domain
비즈니스 규칙과 정보에 대한 실제 도메인 정보가 있는 패키지이다. 도메인의 변경과 같은 로직이 구현될 수 있다.
Infrastructure
외부 시스템을 호출하는 역할이다. JPA 사용 시, 이 패키지에 관련 Repository 클래스를 작성한다.
'ETC' 카테고리의 다른 글
| Git 브랜치 전략과 Git Merge vs Rebase (0) | 2025.02.13 |
|---|