Domain-driven design Quickly - introduction

Domain-driven design이  필요한 이유..

SW관련자들은 '문제영역'을 SW구현기술, 아키텍처에 투영하여 SW시스템으로 만드는데,
'도메인' 자체와 너무도 동떨어진 세계의 무언가.. 로 복잡하게 만들어 왔다는 것이 문제로 대두..
문제는 SW관련자에 의한 설계나 개발요소가 무엇인지, 뭘하는건지.. 알아보기 너무도 힘들다는 거..
심지어는 SW를 만든 'architect'도 간혹.. 이것이 내가 만들려던 것이였는지 조차 알아볼 수 없는 상황이 연출..

'무시무시한 기존의 Architect'
~사상을 차용하고 ~패턴~패턴~패턴을 엮어서 성능을 위해 이렇게 엮어서..
최근의 이슈인 ~를 적용해서 마지막으로 우리 프로젝트 사상과 엮어서 이렇게 구성해봤소..
후후후후~ 이것이 바로 엘레강스함 그 자체인 스포츠카 시스템이라 할 수 있지.. 으쓱~

=> 자네는 어느 행성에서 왔소?
      우리가 궁금한건 오로지 머릿속에 그려왔던 '스포츠카'가 만들어지고 있는지.. 뿐이라오.

문제의 본질인 '도메인'에 집중하고
그것이 소프트웨어 분석/설계/구현의 중심이 될 필요가 있다.
'도메인'을 왜곡시키지 않는 '도메인'에 친화적인 'SW모델'을 만들어,
'도메인'을 아는 누구든 의사소통 가능한 'SW모델'을 만들자는것.. 그게 'DDD'

문제의 본질인 '도메인'에 집중하고 그것이 소프트웨어 분석/설계/구현의 중심이 될 필요가 있다.


이것이 바로 'Domain-driven design'.