Page History

DDD 요약

모두가 동의할수 없으나, 간단하게 애자일과 DDD를 한문장으로 정의해보자

• 애자일 : 예측 불가한 도메인때문에 ,프로젝트의 라이프 사이클을 짧게하여,지속 수정 가능한 유연한 개발방법 도입 ( 주로 폭포수모델의  한계점을 예를듬)
• DDD : 오늘날 소프트웨어 복잡성은 기술보다 도메인의 복잡성및 변화에 기인하며 도메인을 중심에 두고 소통하고 발견하는 개발방법 도입 ( 주로 전문가와 단절이 된체 기술중심으로 문제를 해결하는 방식의 단점을 예를듬)

이야기하는 패러다임은 완전하게 다르나,변화하고 복잡해지는 비지니스 모델에 대응하기위해

어떠한 개발 문화를 가져야할까? 고민하는 부분은 동일하며  목표 달성을 위해 사용하는 도구 또한 상당수 공유하고 있습니다.

애자일이 주로 개발문화에대해 영향을 주었다고하면, DDD는 구현코드에서 도메인의

...

특성을 반영해야하는것을 중요하게 생각하며,구체적인 구현편으로 이어집니다.

애자일또한 이러한 구현에대해 중요하게 생각하고 있었으나 구체적으로 정리된 버전은 존재하지 않습니다.

...

그러한 의미에서 애자일의 연속성에서 DDD는 중요한 의미를 가집니다. DDD의 구현편은  다양한 프레임워크에서 구현편이 존재하며 마이크로 서비스에서도 DDD가 적용되고 있는 추세입니다. (국내는 제외)

정작 마이크로서비스,쿠버네틱스등 국내에서도 인프라적인 이야기는 많이 되고 있으나  마이크로 서비스 구현체에 활용될수 있는 DDD의 자료가 거의 없거나 정착이 되지 못하는것은 다소 안타깝습니다. 

웹영역에서는 OOP를 개발자의 기술적 역량 파악하는데만 사용 되어왔으며  EJB/컨테이너/컴퓨넌트 모델방식으로 어디에 코딩해야하는지만 신경을 쓰게되었으며

개발자는 OOP능력을 대부분 상실해 갔습니다. 결국 이것은 도메인 모델링자체가 실종하는 결과가 되었으나 그래도 작동해 왔습니다. 

그동안 객체지향 사상을 기업 규모 어플리케이션이 어떻게 적용할지에 대해 분명한 비전이 없었다란점을 감안하면 

DDD는 비지니스 문제 해결을 위해 OOP의 능력을 활용하고 구현체를 제안 하고 있으며 , 이러한 이유로 DDD는 엔지니어 개발자로서 중요하다고 생각합니다. 

구현없이 클릭만으로 모든 비지니스 모델을 만들수 있는 그런시대가 분명 올지도 모르지만 

DDD는 생소한것이 아니고, 이제는 다양한 웹프레임워크에 녹여있으며 쉽게 검색가능합니다. (국내 적용사례는 거의 없음)

( MVC가 그래왔던 것처럼 빠르게 뿌리내리지는 못할것같으나 언젠가는 국내에서도 활용하는 기업이 생겨날것으로 기대해봅니다.)

• https://www.baeldung.com/spring-data-ddd
• https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation
• https://medium.com/bestmile/domain-driven-event-sourcing-with-akka-typed-5f5b8bbfb823
• https://medium.com/@qasimsoomro/building-microservices-using-node-js-with-ddd-cqrs-and-event-sourcing-part-1-of-2-52e0dc3d81df
• https://microservices.io/patterns/data/domain-event.html

경계해야할것

작업셔플

작업 셔플 만을 이용하여  스토리를 잘정리하고,스프린트 단위로 잘 분류하여  프로젝트를 성공시킨다.

...