Download to read offline
![[아꿈사/110903] 도메인주도설계 4장](https://cdn.slidesharecdn.com/ss_thumbnails/110903-110903003107-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Event Storming(이벤트 스토밍)
- 1. S TAT EO R E V E N T S ? W H I C H S H A L L I K E E P ?
- 2. S P RI N G D E V E L O P E R A D V O C AT E AT P I V O TA L • Blogger, Programmer and Trainer @Bottega • Loves to tackle complex enterprises with: Domain-Driven Design, Test- Driven Development and Spring tools. Being a micro service freak, architecture is his main area of interest too. • When he does not program he rides motorbike, skis or grows his beard. • Also, here is his DZon MVB award blog: pillopl.github.ui • Co-founder of twitter #dddbyexamples initiative: github.com/ddd-by-examples
- 3. O O PM O D E L I N G W I T H T D D E V E N T S O U R C I N G E V E N T- D R I V E N A R C H I T E C T U R E
- 4. P R IN C I P L E S F O R D E L I V E R I N G S O F T WA R E FA S T E R W H I L E I N C R E A S I N G R E L I A B I L I T Y. • UNDERSTAND • DIVIDE • 모듈의 분리 Clean Architecture(P104) - REP, CCP, CRP • IMPLEMENT • DEPLOY • BUILD VALUE • Allow developers to spend as much time as needed on understanding the business domain itself.
- 5. T E RM D E S C R I P T I O N • Domain Model • 소프트웨어를 만들기 위한 ‘비즈니스’를 이해하는 것과 관련해서 이야기하자면 우리의 이해를 돕거나 복잡한 도메인을 모델링하기 위한 마법적인 프로그래밍 프레임워크는 존재하지 않습니다. 나는 도메인이 미래에 어떻게 발전하고 변화 할 것인지 예측하는 것이 불가능 하기 때문에 이런 프로그래밍 프레임워크가 나올 것이라고는 기대하지 않습니다. 그 러나 판매, 인벤토리, 제품 카탈로그와 같은, 대부분의 사람들이 익숙해져야하는 몇몇의 공통된 추상적인 도메인들이 있습니다. 처음부터 바퀴를 다시 만들 필요는 없습니다. 복잡한 도메인 모델링을 위한 훌륭한 참고자료가 있습니다. Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML (https://www.amazon.com/Enterprise-Patterns-MDA-Building-Archetype/dp/032111230X) • Understand, Divide, and Continuously Conquer • 빠르게 소프트웨어를 Delivery해 나갈 때, 추후에 다른 사람들이 어떻게 코드를 이해할지 신경쓴느 것 때문에 지체하 면 안됩니다.(시간을 희생해서는 안된다.) 고맙게도 우리는 DDD의 형태로 일련의 원칙과 관행을 가지고 있습니다. 개 인적으로 나는 DDD를 미지의 것을 반복적으로 학습하는 과정이라고 생각하고 싶습니다. DDD적용의 부차적인 효과 는 개발자와 비즈니스 모두에게 코드를 더 이해하기 쉽고 확장 가능하며 일관성있게 만들 수 있다는 것입니다. DDD 를 사용하면 소스 코드는 도메인이 어떻게 작동해야 하는지를 설명하는 지를 설명하는 좋은 길잡이가 됩니다. 소프트 웨어의 기능들은 변경될 수 밖에 없습니다. 그런데 개발자가 Source Code를 그들이 이해한 용어로 비즈니스에게 설 명하지 못한다면 그 작동은 장식에 불과하며 변형이나 대체가 힘들어 지게 됩니다. 심지어 가장 복잡한 도메인 마저도 다음과 같이 분해되어야 합니다. ‘Core Domain’, ‘SubDomain’
- 6. T E RM D E S C R I P T I O N • Core Domain • 작지만 가장 복잡한 서브도메인(so-called ‘코어 도메인’) - 아마도 우리 기업 경쟁력의 핵심적인 부분으로 많은 노력을 투자해야 하는 도메인 • Sub Domain • 엔터프라이즈에 고유하지 않은 간단하고 이해하기 쉬운 도메인 (“generic subDomain”) - 기업용 어플리케이션이 동작하게 도움을 주 지만 경쟁 우위를 제공하지는 않습니다. 인벤토리 또는 인보이스를 예를 들명 좋을 것 같습니다. 가장 예쁜 청구서를 만든다고 하여도 고객들은 그 다지 좋아하지 않을 것입니다.
- 10. 이러한 작은 제품들을확인해보면 우리에게 우리의 코드가 어떻게 모듈로 만들어져야 하는지에 대 한 초안을 제공해줍니다. 각각의 서브 도메인은 분리된 모듈과 같은 개념을 가지고 있습니다. 핵심 도메인과 일반 도메인의 차이를 이해하는 것은 우리가 다른 건설적인 스타일을 필요로 할 지도 모 른다는 사실을 자각할 수 있게 도와줍니다. 다행히도 다음 링크에 들어가 보면 알 수 있듯이 우리 가 고르고 선택할 수 있는 다양한 재료들이 있습니다.
- 11. U N DE R S TA N D • EVENT • 도메인 전문가가 관심을 가지고 있는 어떤 사 건 • 연속된 개발 이벤트를 묶어서 도메인에서 일어 나는 활동의 정보를 모델링하자. 각 이벤트를 도메인 객체로 표현하자… 도메인 이벤트는 도메인 모델을 완벽히 지원하며 도메인에서 일 어난 어떤 사건을 나타낸다. • “~~ 할 때~ • “그런 일이 일어나면…” • “… 하면 저에게 알려주세요.”와 “…하면 저에게 통보해주세요” • “…한 일의 발생”
- 12. U N DE R S TA N D • Command • 이벤트의 원인을 파악해야 합니다. 도메인 전문 가들은 그 원인을 알고 있고, 그것을 대부분 다음 과 같이 적절히 분류할 수 있습니다. • 시스템에 대한 직접적인 명령 - 이벤트 옆에 파란색으로 표시 • 다른 이벤트 - 이 경우 우리는 이벤트를 각각 의 이벤트옆에 표시합니다. • 주기적으로 동작해야 하는 이벤트 - time으 로 작게 표시하도록 합니다. • 녹색의 조그만 카드는 조회와 읽기 모델을 나타냅니 다. • CQRS : Command and Query Responsibility Segregation
- 13. U N DE R S TA N D • Invariants • 이번 단계가 매우 중요합니다. 우리는 원인만 으로 도메인 이벤트가 발생하는데 충분한 가를 알 필요가 있습니다. 아마도 충족시켜야할 다 른 조건이 있을 것입니다. 아마도 한개 혹은 여 러개의 원인이 있을 수 있습니다. 이런 조건들 을 invariants라고 말합니다. 그렇다면 우리는 그 원인을 적고 노란색 노트로 command, event 사이에 붙여 놓습니다. • 일련의 과정들을 보면 우리는 우리 도메인이 무엇을 하는지에 대한 좋은 관점을가질 수 있 습니다. 게다가 우리는 기본적인 비즈니스 프 로세스에 대하여 배울 수 있습니다. 이 기술은 문서와 UI Mockup과 비교해서 보다 가볍고, 빠르며, 재미있고 좀 더 서술적입니다. 지금까 지 코드는 한줄도 없습니다.
- 14. U N DE R S TA N D • Divide • invariants를 확인하기 위해서 우리는 몇 가지 질 문을 할 필요가 있습니다. 인출을 하려면 이미 정 해진 한도가 있어야 한다. 시스템은 반드시 다음의 질문을 해야 합니다. “정해진 한도를 가지고 있습 니까? “, 반면 질문에 대한 답변에 변화를 줄수도 있는 command와 event가 있습니다. 이러한 관계들 은 명확하게 높은 응집도를 가지고 있습니다. 이것 은 모듈과 클래스를 구분해 주는 좋은 기준이 됩니 다. • 이 경험을 모든 곳에서 적용해 보겠습니다 .초록색 노트에서 각 invarient를 처리하기 위해서 필요한 query/view의 이름을 기록합니다. 또한 해당 query/view에 대한 응답이 이벤트의 결과를 변경 할 때를 강조 표시합니다. 그렇게 하면 초록색 메 모가 invarient 옆이나 이벤트 옆에 나타납니다.
- 15. D I VI D E • Command / Event Pattern • CmdA로 인하여 EventA가 발생합니다. • EventA는 SomeView에 영향을 미칩니다. • CmdB가 처리되는 동안 SomeView가 필요합니다. • 이것은 CmdA, CmdB가 같은 모듈의 후보가 될 수 있음을 의미합니다. • 이제 이 commands(Event, Invariant와 함께) 같이 놓도록 합니다. 이렇게 한다면 도메인을 매우 응집력 있게 설계할 수 있습니다. 이렇게 다음 장과 같이 모듈로 나누었습니다. 이 것은 단지 경험적일 뿐이라는 것을 기억하십시오. 다른 설계로 바뀔 수도 있습니다. 이렇게 위에서 부터 나온 분석 들로 인하여 우리는 결합도가 약한 모듈을 설계할 수 있습니다. 이같은 경험적인 방법으로 우리는 독립적인 모듈 들을 찾아낼 수 있습니다. 또한 이것에 대해서 생각해보면 제안된 모듈들은 언어적인 경계를 가지고 있습니다.
- 17. U N DE R S TA N D • Divide 해당 단계의 마지막은 이 모듈들이 어떻게 통신하는지(context- mapping)를 살펴보는 것입니다. 여기 몇 사례들이 있습니다. • 모듈은 다른 모듈에게 쿼리를 보낸다. - Statement module은 card operations에게 어떤 인출이 있었는 지 질의해 봐야 합니다. 만약 인출이 없다면 그것은 Statement에 아무일도 일어나지 않았기 때문입니다. • 모듈은 다른 모듈로 부터 보내진 이벤트를 수신합니다. - Money Repaid 이벤트의 직접적인 결과는 Statement Closed 이벤트입니다. 이 것은 Statements가 Card Operations으로 부터 발행된 메 시지를 구독한다는 것을 나타냅니다. 그것은 Event Storming 세션의 시작 부분에 놓친 것입니다. 컨텍스 트 매핑은 실제로 많은 새로운 정보를 발견하는 과정입 니다. • 모듈은 다른 모듈의 command를 실행시킵니다. 아직 이 예제는 없네요.
- 18. I M PL E M E N T
- 19. I M PL E M E N T
- 20. I M PL E M E N T
- 21. I M PL E M E N T
- 22. I M PL E M E N T
- 23. I M PL E M E N T
- 24. I M PL E M E N T
- 26. – D OB A N “Question???”