Domain Driven Desgin(DDD)에 대해서 알기 위해서는 도메인에 대해서 알아야 합니다.
보통 사용자가 사용하는 것을 도메인(Domain)이라고 합니다.
예로 어떠한 사이트에서 유저가 회원가입을 하는 것을 도메인이라고 할 수도 있고,
유저가 상품을 결제를 하는 행위를 도메인이라고 할 수도 있고, 쇼핑몰 관리자가 상품을 관리하는 것을 도메인이라고 할 수도 있습니다. 사용자가 사용함으로써 의미를 가지는 행위를 도메인이라고 합니다.
여러가지 도메인들이 서로 상호작용 하며, 설계하는 것이 바로 도메인 주도 설계입니다.
DDD를 프로젝트에 반영하기 위해서는 기술보다는 도메인이 더 높은 순위로 우선순위를 가져야하고, 어떤 문제를 실행하기 위해서는 항상 도메인을 먼저 고민하는 것을 필요로 합니다.
특정 모델이 어떤 Bounded Context에 놓이는가에 따라 다르게 이해될 수 있다라는 특징이 있습니다.
예로 회원가입 도메인에서 유저정보는
유저 입장에서는 회원가입을 하기 위한 객체 정보 (아이디, 비밀번호,이름 ,나이 등)를 담고 있지만,
관리자 입장에서는 회원을 관리하기 위한 객체 정보 (생성날짜, 개인정보수집 유효기간 등)을 담고 있습니다.
Bounded Context에 따라서 모델들의 역할은 완벽히 달라지고, 책임 또한 달라지게 됩니다.
문맥에 따라서 객체의 역할이 바뀌기 때문에 도메인 주도 설계에서 같은 객체(Object or Class)가 여러개 존재할 수 있다는 것이 특징입니다.
Bounded Context를 개념을 놓고 도메인을 생각해본다면 각각의 도메인은 서로 철저히 분리되고, 높은 응집력과 낮은 결합도로 설계되어야 합니다.
설계한 도메인을 모듈별로 분리하는 것을 마이크로서비스라고 합니다.
이로써 코드의 가독성과 함께 복잡성을 관리할 수 있고, 불필요한 시간의 소비와 예상치 못한 side-effect를 최소화할 수 있습니다.