오늘은 설계에 대한 내용을 준비했다.
많이 쓰이는 패턴들이지만 정확한 의미를 알고자 준비해보았다.
가장 대표적인 MVC, FACADE, DDD 에 대해 차이점을 분석해보았고 차근차근 내용을 추가해볼 생각이다!
1. 소프트웨어 설계 접근
가장 대표적인 예로는 역시 도메인 주도 설계, DDD(Domain-Driven Design) 가 있을 것이다!
그 전에 일단 "도메인"에 대한 정의를 해보겠다.
2. DOMAIN?
도메인의 사전적 의미는 '영역', '집합' 이다.
DDD에서 말하는 도메인은 비즈니스 도메인을 말하며, 즉 업무의 집합이라고 볼 수 있다.
예를 들어보자,
- 쇼핑몰에서는 손님들이 주문하는 도메인(Order Domain)이 있을 수 있다.
- 직원입장에선 옷들을 관리하는 도메인(Manage Domain)이 있을 수 있다.
- 결제를 담당하는 도메인(Payment Domain)이 있을 수 있다.
이렇게 여러 가지 도메인들이 상호작용하며, 비즈니스 도메인별로 나누어 설계하는 것이 바로 도메인 주도 설계이다!!
3. 도메인(domain)과 객체의 차이
객체는 추상화 또는 구체화할 수 있는 특정 요소만을 표현하는 반면,
도메인은 사용자가 사용하는 모든 것을 설명할 수 있다.
⭐ 여기서 퀴즈~⭐
"고양이는 사과를 먹는다"
다음 문장에서 객체의 관점과 도메인의 관점을 비교해보자!
5
4
3
2
1
.
.
객체의 관점에서는 "고양이"와 "사과"를 표현할 수 있고, "먹는다"는 객체가 하는 행위로 별도로 표현한다.
도메인의 관점에서는 "고양이", "사과", "먹는다", "고양이는 사과를 먹는다." 모두 각각 도메인이라고 할 수 있다.
즉
- 객체란 현실 그대로를 표현한다.
- 도메인은 사용자가 바라보는 관점에 따라 구분할 수 있다.
🤯그렇다면?🤯
도메인은 명확하게 정해져 있지 않다는 건데 사용자가 바라보는 관점에 따라 바뀐다는 의미 아닌가?
맞다!!!!!!! 조금 더 정확한 표현으로 말하자면 문맥(CONTEXT)에 따른다 라고 한다.
4. Bound Context (문맥의 경계)
사용자가 어떤 문맥으로 설계를 하느냐에 따라, 각 도메인에 들어갈 수 있는 객체는 달라질 것이다. 또는? 같은 객체가 여러 도메인 내에 존재할 수도 있다.
예를 들어보자
주문 도메인에서의 옷은 손님들에게 팔기 위한 객체 정보(name, price .. etc)들을 담고 있지만,
옷을 관리하는 도메인에서는 옷은 점주 입장에서 관리하기 위한 객체 정보(madeTime, size, madeCountry ... etc)들을 위주로 담고 있습니다.
다시 말해, 문맥에 따라 객체의 역할은 바뀔 수 있다는 의미이다.
(위 그림은 하나의 "옷" 객체가 2가지의 도메인으로 나뉠 수 있다는 것을 의미한다.)
그렇다면 어떻게 해야 객체지향적인 설계를 할 수 있을 것 인가?
도메인은 알겠는데 그래서 추구하고자 하는 게 뭘까?
5. DDD의 핵심 목표
High cohesion, Loosly coupling!!
각각의 도메인은 서로 철저히 분리되고, 높은 응집력과 낮은 결합도로 변경과 확장에 용이한 설계를 얻게 된다.
무슨 말인지 나도 이해가 안간다! 그래서 위의 예제로 다시 한 번 더 설명해보겠다.
예시: 옷 객체의 도메인별 역할
1. 주문 도메인
- 문맥
: 고객에게 제품을 판매하는 상황 - 옷 객체의 역할
: 손님들에게 팔기 위한 정보 제공 - 목적
: 고객의 구매 결정을 지원하고 판매 프로세스를 관리 - 높은 응집력
: 해당 도메인 내 모든 속성과 메서드가 고객에게 제품을 판매하는 것과 관련이 있습니다.
2. 재고 관리 도메인
- 문맥
: 점주 입장에서 제품을 관리하는 상황 - 옷 객체의 역할
: 제품의 관리 정보 제공 - 목적
: 재고 상태를 모니터링하고 공급망 및 제품 품질을 관리 - 높은 응집력
: 모든 속성과 메서드가 재고 및 제품 관리를 중심으로 구성됩니다.
높은 응집력(High Cohesion)
각 도메인의 응집력:
주문 도메인의 옷 객체는 판매와 관련된 기능과 정보를 중심으로 설계되어 있으며, 관련된 기능들이 함께 그룹화되어 있습니다.
재고 관리 도메인의 옷 객체는 관리 및 재고와 관련된 속성과 기능을 포함하여 응집력이 높습니다.장점:
관련 기능이 모여 있어 코드의 가독성과 유지보수성이 향상됩니다.
도메인의 요구사항이 명확하게 반영되어 코드의 의도가 분명합니다.
각 도메인이 독립적으로 변화할 수 있으므로 변경 관리가 용이합니다.
낮은 결합도(Loose Coupling)
-
도메인 간의 결합도:
주문 도메인과 재고 관리 도메인은 서로 독립적으로 설계되어 있습니다.
한 도메인의 변경이 다른 도메인에 영향을 미치지 않습니다. -
장점:
도메인 간의 상호 의존성을 줄여 변경의 영향을 최소화합니다.
각 도메인은 독립적으로 테스트 및 배포할 수 있습니다.
새로운 요구사항이 추가되거나 변경될 때, 특정 도메인만 수정하면 되므로 확장이 용이합니다.
