도메인이란?
개발자 입장에서 구현해야 할 소프트웨어 대상은 서비스 내 여러 가지 기능을 제공하고 있고, 해당 서비스는 소프트웨어로 해결하고자 하는 문제영역 도메인(domain) 에 해당합니다. 하나의 도메인은 다시 하위 도메인으로 나눌 수 있으며, 하나의 하위 도메인은 다른 하위 도메인과 연동해 완전한 기능을 제공하게 됩니다.
예를 들어, 온라인 배달 시스템은 소프트웨어 대상이자 도메인에 해당하고, 하위 도메인으로는 입점하는 업체, 광고, 결제, 주문, 상품(음식), 배송 등이 해당하게 됩니다. 그리고 고객이 음식을 주문하게 되면 상품, 주문, 결제, 배송 하위 도메인이 서로 연결됩니다.
도메인이 제공해야 하는 모든 기능을 직접 구현하는 것은 아니며, 일부 기능만 자체 구현하며, 나머지 기능은 외부 업체의 시스템을 연동하여 사용하는 경우도 많습니다.
또한, 도메인마다 하위 도메인이 존재하는 것은 아니며, 하위 도메인을 어떻게 구성할지에 대해서는 상황에 따라 달라집니다.
도메인 모델
도메인 모델에는 다양한 정의가 존재하며, 기본적으로는 특정 도메인을 개념적으로 표현한 것을 의미합니다.
상품 도메인을 생각해 보면, 상품에는 여러 개의 옵션이 존재하며, 옵션별로 가격과 수량을 설정할 수 있습니다. 추가로, 어떤 결제 수단으로 구매할 수 있는 상품인지, 출고지와 배송 방법 옵션별로 혹은 상품별로 몇 개씩 구매 가능한지 구매 제한 등에 대한 정보를 가지게 됩니다.
도메인 모델을 사용하면, 동일한 모습으로 도메인을 이해하고 지식을 공유하는 데 도움이 됩니다.
도메인을 이해하기 위해서는 도메인이 제공하는 기능, 주요 데이터 구성을 파악해야 하는 측면에서 기능과 데이터를 함께 보여주는 객체 모델은 도메인을 모델링하기에 적합합니다.
도메인 모델은 객체로만 모델링 할 수 있는 것은 아니며, 상태 다이어그램, 클래스 다이어그램, 그래프(관계가 중요한 경우)를 이용해서도 도메인을 모델링 할 수 있습니다. 도메인을 이해하는 데 도움이 된다면 어떻게 표현하는지에 대해서는 중요하지 않습니다.
도메인 모델은 도메인 자체를 이해하기 위한 개념 모델입니다. 개념 모델만으로 바로 개발할 수 있는 것은 아니므로, 구현 기술에 맞는 구현 모델은 따로 필요합니다.
하위 도메인이 다루는 영역이 서로 다르기 때문에 같은 용어일지라도 하위 도메인 별로 의미가 달라질 수 있습니다. 도메인에 따라 용어 의미가 결정되므로 여러 하위 도메인을 하나의 다이어그램에 모델링하면 안 됩니다. 모델의 각 구성요소는 특정 도메인으로 한정할 때 의미가 완전해지므로, 각 하위 도메인별로 각각 모델을 만들어야 합니다.
도메인 모델 패턴
일반적으로 애플리케이션 아키텍처는 표현-응용-도메인-인프라스트럭처와 같이 네 개의 영역으로 구성됩니다.
| 영역 | 설명 |
|표현(UI) | 사용자 요청을 처리하고 사용자에게 정보를 보여줍니다. 이때, 사용자는 외부 시스템일 수도 있습니다.|
|응용 | 사용자가 요청한 기능을 실행합니다. 도메인 계층을 조합해서 기능을 실행하며, 업무 로직을 직접 구현하지 않습니다.|
|도메인 | 시스템이 제공할 도메인 규칙을 구현한 부분입니다.|
|인프라 |외부 시스템과의 연동을 처리합니다. ex) DB, 메세지 시스템|
도메인 모델 패턴은 아키텍처 상의 도메인 계층을 객체 지향 기법으로 구현하는 패턴을 의미합니다.
- 도메인 계층 : 도메인의 핵심 규칙을 구현
예를 들어 상품 도메인에서 '상품은 노출 상태가 노출 중인 경우에만 카테고리에 노출된다'라는 규칙과 '일부 상품 정보는 최초 주문 발생 전에만 수정할 수 있다'라는 규칙을 구현한 코드가 도메인 계층에 위치하게 됩니다.
여기서 중요한 부분은 핵심 규칙을 구현한 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야 하는 경우 다른 코드에 영향을 덜 주면서 변경 사항을 반영할 수 있습니다.
개념 모델과 구현 모델
개념 모델은 문제를 분석한 결과물로 실제 구현하는 부분에 대해서는 고려하지 않고 있기 때문에, 코드를 구현하면서 개념 모델을 있는 그대로 사용할 수 없습니다. 그래서 개념모델을 구현 모델의 형태로 전환하는 과정을 거치게 되며, 개발하는 동안 해당 도메인에 대한 이해도가 높아지기도 하고 새로운 통찰을 얻으며 완전히 다른 의미로 해석되는 경우도 있습니다. 처음부터 완벽한 개념 모델을 만들기보다 전반적인 개념을 알 수 있는 수준으로 모델을 작성하는 것이 좋으며, 구현하는 과정에서 개념 모델을 구현 모델로 점진적으로 발전시켜 나가는 것이 좋습니다.
'개발' 카테고리의 다른 글
DIP 의존 역전 원칙 (0) | 2024.09.21 |
---|---|
DDD - 도메인 모델링 (0) | 2024.09.20 |
TDD (테스트 주도 개발) (1) | 2024.09.18 |
동기/비동기 (0) | 2024.09.18 |
JPA 연관관계 (2) | 2024.09.18 |