Strategie integracji między kontekstami w Domain Driven Design

W idealnym świecie DDD dany Bounded Context jest w pełni niezależny, odizolowany od otoczenia, posiada wszystkie informacje niezbędne do realizacji swoich celów biznesowych. Niestety nie zawsze mamy taki komfort, a przyczyn może być wiele. W efekcie jesteśmy zmuszeni do zapewnienia brakującej wiedzy naszemu kontekstowi. W ramach prezentacji przedstawię niektóre ze strategii integracji między kontekstami, kładąc szczególny nacisk na stronę praktyczną czyli kod.

Przykłady użyte w prezentacji można znaleźć https://github.com/tswiackiewicz/phpers-summit-2019

Transcript

1. Strategie integracji między kontekstami w Domain Driven Design Tomasz Świacko-Świackiewicz tswiackiewicz@getresponse.com
2. Tomasz
 Świacko-Świackiewicz • Software Architect
 @ GetResponse • Software Craftsmanship
 Clean Code • Domain Driven Design • search engines tswiackiewicz.github.io/inside-the-source-code/
3. Components, services • Service Oriented Architecture (SOA) • SOAP • REST source: en.wikipedia.org
4. • Enterprise Service Bus (ESB) • Kafka source: sovtex.ru Components, services
5. • Enterprise Integration Patterns (EIP) • messaging patterns source: enterpriseintegrationpatterns.com Components, services
6. • microservices • sync (REST) vs async (EDA) source: devopedia.org Components, services
7. Components, services source: twitter.com
8. • focus on core domain, domain logic • set of principles & patterns
 NOT technology
 NOT methodology • ONLY for complex 
 business problems source: amazon.com , leanpub.com Domain Driven Design
9. Domain Driven Design • Ubiquitous Language • Bounded Context • Domain Model
10. • Entities • Value Objects • Aggregates • Services • Factories • Repositories Domain Driven Design
11. Domain Driven Design source: dddsample.sourceforge.net
12. • Shared Kernel • Anti-corruption Layer • Customer / Supplier Integration strategies
13. • Conformist • Open Host • Published Language • Separate Ways Integration strategies
14. source: beveragedaily.com
16. Layered Architecture • Beer • Application • Domain • Infrastructure (db, HTTP) • Shared • Rating (legacy) • Shared • User
17. Command Factory • always valid • all required data in command • Factory Design Pattern
18. Command Factory
19. Application Service • orchestration • data hydration • validation
20. Monolith Database • “communication” interface • database per service (microservices) • coupling (schema, data, deployment, …)
21. Anticorruption Layer • Adapter Design Pattern • domain concept - Ubiquitous Language • legacy code integration • external code integration • 3rd party • microservices
22. Anticorruption Layer
23. Anticorruption Layer
24. Summary • software can be is complex • modularity • DDD is a WAY OF THINKING • always valid • layered architecture
25. Q & A
26. Thank You Tomasz Świacko-Świackiewicz tswiackiewicz@getresponse.com
 
 tswiackiewicz.github.io/inside-the-source-code/ http://bit.ly/phpers-ddd- bounded-context-integration