1. 나에게 도메인 주도 설계는
DDD가 우리에게 상처를 줄까?
도메인 주도 설계는 복잡한 접근법이 아니라 복잡한 소프트웨어 프로젝트에 사용할 수 있는 수준 높은 기술들을 모은 것.
DDD는 복잡성을 이기는 데 수반되는 고통을 덜어줄 것.
좋은, 나쁜 그리고 효과적인 설계
지식 획득은 감안하지 않고 일정 관리를 위해 스크럼을 사용하는 경우, 일정 압박으로 인한 잘못된 설계를 하게 되곤 함.
- 소프트웨어 개발을 이익 중심이 아닌 원가 중심으로 생각.
- 개발자가 너무 기술에만 몰두한 나머지 문제를 신중하게 연구하고 설계하기보다는 기술적으로 해결하려 함.
- 데이터베이스에 너무 큰 우선순위를 부여함.
- 비즈니스가 담고 있는 멘탈 모델과 개발자가 만들어낼 소프트웨어 사이에 큰 차이를 야기함.
- 비즈니스와의 협업이 빈약.
- 프로젝트에 대한 예측을 매우 강하게 요구함. 적절하게 분리된 모델이 아닌 큰 진흙 덩어리를 만들게 됨.
- 개발자가 비즈니스 로직을 사용자 인터페이스 컴포넌트와 영속성 컴포넌트 안에 담게 됨.영속성 오퍼레이션을 비즈니스 로직 중간에 수행하기도 함.
- 잘못된 추상화가 존재.
- 강하게 결합된 서비스가 존재. 시스템 유지보수가 어려워지고 종종 비즈니스 프로세스에 문제를 일으키고 데이터가 불일치되게 됨.
"설계하지 않는 것이 낮은 비용의 소프트웨어로 이어진다"라는 사상은 잘못된 오류. "좋은 설계의 대안은 나쁜 설계, 절대 설계하지 않는 것이 아니다."
효과적인 설계는 조직이 무엇에 강점을 가져야 하는지 이해시키고, 정확한 소프트웨어 모델을 생성하도록 가이드.
전략적 설계
전략적 설계부터 시작하여 전술적 설계를 적용. 전략적 설계는 세세한 구현으로 들어가기에 앞서 두터운 붓 터치처럼 사용.
- 바운디드 컨텍스트(Bounded Context)
- 보편언어(Ubiquitous Languate)
- 서브도메인(Subdoumains)
- 컨텍스트 매핑(Context Mapping)
- 컨텍스트 맵(Context Map)
전술적 설계
전술적 설계는 도메인 모델의 세부사항들을 그리기 위해 얇은 붓을 사용하는 것과 같음.
- 엔티티(Entity)
- 값 객체(Value Object)
- 애그리게잇(Aggregate) 패턴
- 도메인 이벤트(Domain Events)
학습 과정과 지식의 정제
출처
