도메인 주도 설계 - DDD

🚀 질문

질문은 기술적인 지식 뿐만 아니라 자신이 사용하고 있는 기술을 지식적으로 적립되어 있는지 질문을 했다.
다음은 답변하지 못한 질문의 키워드 이다.

🌠 DDD (Domain Driven Design)

해당 도메인 전문가의 입력에 따라 도메인 을 일치시키는 모델링 소프트웨어에 중점을 둔 소프트웨어 설계 접근 방식으로
그 핵심은 Loose Coupling, High Cohesion 으로 각 도메인이 연결성이 적고 높은 정도로 연관되어 보다
가벼운 설계를 위해 만들어 졌다.

Eric Evans가 출간한 도메인 주도 설계-소프트웨어의 복잡성을 다루는 지혜 에서는 DDD를

소프트웨어를 이해하고 프로젝트를 성공적으로 완성하기 위한 사고방식

으로 정의하였다.

새로운 방식의 개발 방법이 아닌 SW의 복잡성을 최소화 하고 설계의 범위와 방향의 일관성을 유지하기 위한 방식 이기 때문이다.

DDD vs OOP

DDD와 OOP 모두 설계 과정을 쉽게 하기 위해서는 다르지 않다.

관점에서 바라본다면 도메인과 객체의 관점에서 그 차이가 보일 것이다.
객체는 현실 그대로를 표현하고 있고, 도메인은 사용자가 바라보는 관점에 따라 각각을 구분하거나 전체라고 할 수 있습니다.

고양이는 사과를 먹는다.

객체의 관점에서는 “고양이”와 “사과”를 표현할 수 있고, “먹는다”는 객체가 하는 행위로 별도로 표현합니다.

도메인의 관점에서는 “고양이”, “사과”, “먹는다”, “고양이는 사과를 먹는다.”

모두 각각 도메인이라고 할 수 있습니다.

여기서 문제는 도메인은 그 범위가 불명확하다는 것이다.

도메인은 사용자의 관점에 따라 혹은 사용성에 따라 계속해서 바뀔 수 있기에 그 형태가 정해져있지 않다.

☄ DDD의 세가지 주요 원리

1. 핵심 도메인과 그 기능에 집중하라.
2. 도메인의 모델의 정교하게 구축하라.
3. 어플리케이션 모델을 발전시키고 새롭게 생기는 도메인 관련 이슈를 해결하기 위해 도메인 전문가와 끊임없이 협력하라.

🧾 Reference

OOP vs DDD

도메인 주도 설계(Domain-Driven Design) in Real Project — 도메인