DDD에서 구현이란 , 분석모델이 별도로 존재하는 이분법을 채택하지 않고 설계와 코드를 일치시키는것이 핵심!
코드의 변경이 곧 모델의 변경이라는 점을 인식해야하는 점과, 설계자가 구현을 하지 못해 개발자와 업무의 단절이 생기면
설계자의 지식과 솜씨는 결코 전달되지 않기때문에 실천적 모델(HANDS-ON MODELER)을 각 프로그래머가 수행해야하며
이것은 역활과는 상관없이 코드를 변경하는 책임이 있는 이들은 코드를 통해 모델을 표현하는 방법을 배워야한다란것을 강조하고 있습니다.
DDD는 단순 코더가 아닌, 생각보다 높은수준의 개발수준과 성숙한 문화를 요구합니다.
도메인 주도설계 구현에서 사용되는 요소들의 단어들을 간략하게 정리하였습니다.
시대가 흘러감에 따라 더 좋은 개념이 추가될수도 있고 변화가 될수도 있으나, 위와 같은 요소정도로 요약될수 있습니다.
다양한 언어에서 구현된 참고 샘플
- https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation
- http://pkaczor.blogspot.com/2014/04/reactive-ddd-with-akka.html
- http://static.olivergierke.de/lectures/ddd-and-spring/
- https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/ddd-oriented-microservice
- https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/
DDD를 학습하다보면 워터폴의 한계를 이야기 하기도하고 애자일인것처럼 보이기도 하지만 다음과 같이 구분요약될수 있습니다.
- 워터폴은 주로 규모를 어떻게 다룰까? 프로세스를 중요하게생각하며
- 애자일은 규모보다는 변화에 어떻게 대응할가? 절차보다는 유연함을 중요하게 생각하며
- DDD는 복잡성을 어떻게 다룰까? 도메인 전문가의 참여를 중요하게 생각합니다.
DDD와는 애자일은 어떻게 다르고 유사한지? 다음편에서는 애자일의 기원을 찾아가 보겠습니다.
Next : 애자일의 기원을 찾아서
Add Comment