With DDD and self contained systems to a better data architecture

Transcript

1. ENJOY DIGITAL CHANGE WITH DDD AND SCS TO A BETTER DATA ARCHITECTURE
2. WHO WE ARE We consults our customers at their digital challenges and together realise the future. We support our customer with innovative procedures and cutting edge technologies. MISSION 26 years of experience 300+ IT-experts 30 Digitalisations- experts 13 partner 27 parallel development projects BONN BERLIN KÖLN BUKAREST 4 Locations +
3. CHRISTIAN SCHMIDT (36) • from Germany • over 11 years at tarent • Java, Kotlin, Scala, Go, Docker, Kafka, Cloud & cutting Edge • @chris__schmidt • https://github.com/darktoast • https://gitlab.com/christian_schmidt
4. CONWAYS LAW “Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.” - Melvin Edward Conway
5. DDD - DOMAIN / SUBDOMAINS • The domain is separated into subdomains. ◦ Core Domain The core aspects of a corporation. e.G. in a garage the planning or repairs ◦ Supporting Domain Supports the core domain but with less prioritization. e.g. in an eCom domain the evaluation of orders ◦ Generic Domain can be implemented by bought software product. e.g. accounting, project planning
6. DDD - BOUNDED CONTEXT • Bounded Context ◦ The subdomain as “problem space” ◦ The Bounded Context as “solving space” never enfolds the complete domain ◦ Per subdomain a Bounded Context is an ideal fit ◦ Has the data ownership of its enclosing sub domain • A team per bounded context is also ideal
7. Each bounded context encapsulate its own domain related model and owns them. These models are the main data structure of their sub domain. For example customer, order, contract, bill MODEL IN A BOUNDED CONTEXT
8. DDD - UBIQUITOUS LANGUAGE “customer”: { “id”: “c9547a91-...”, “name”: “Max”, “surname”: “Mustermann”, “email”: “m.muster@inter.net”, “address”: “Fakestreet 123” } “newsfeedTarget”: { “name”: “Max”, “surname”: “Mustermann”, “emailAddress”: m.muster@inter.net” } “customer”: { “uuid”: “c9547a91-...”, “firstname”: “Max”, “lastname”: “Mustermann”, “deliveryAddress”: “Fakestreet 123” } Customer Data Newsfeeds Delivery
9. DDD - DOMAIN EVENTS / COMMANDS • The communication between bounded context occurs via domain events ot commands. • Events are passive. ◦ “Something occurs on my side. You can handle it.” • Commands are active. ◦ “I want you to do something!” • Do not mix-up it with synchronous and asynchronous communication! Event: “Customer updated” Command: “Update customer”
10. DDD - SUMMARY • A Bounded Context is a logical and technical encapsulated area which describes a sub domain. • One team owns a bounded context and develops it. • The team has access to domain experts to capture the complete sub domain. • Communications between bounded context occurs via domain events and commands. • Never fixed! Even sub domains and bounded contexts can change over time!
11. fullfillment Marketing customer- management order- management bought ERP old monolith CONTEXT MAP / STRATEGIC DESIGN
12. DDD - STRATEGIC DESIGN PATTERN • Partnership • Customer Supplier • Shared Kernel • Conformist U D U D
13. DDD - STRATEGIC DESIGN PATTERN • Anticorruption Layer • Open Host Service • Published Language D A C L O H S P L
14. DDD - STRATEGIC DESIGN PATTERN • Separate Ways • Big Ball of Mud not a design pattern but often a current landscape
15. • Often domain and technical related separations such as SoA, ESBs, EA, 3-Tier architecture, etc. May be useful. • But also “service bulges”, with central “brightness” to surrounding systems. ◦ Old monolith ◦ But also new distributed big balls of mud ◦ Affects new systems and binds them to it. LEGACY SYSTEMS
16. DDD - ORGANIZATIONAL DRIVEN works fine in green field environments!
17. DDD - SYSTEM DRIVEN As start in brown field environments! Further changes in the system and organization landscape necessary! eg. SAP system eg. old monolith
18. SELF CONTAINED SYSTEMS Bounded Context ⇒ • one self contained system (SCS) • 1 SCS → 1 Team 1 SCS → 1 - n µServices • each SCS has its own UI, services and persistence. • each SCS has its own domain model and ubiquitous language UI model Service UI model Service asynchron
19. SELF CONTAINED SYSTEMS inside synchronous communication eg. Apache Kafka “outer world” data via domain events and commands. The “truth” several consumer
20. THE REAL WORLD - ECOM Landing Search Order Fullfillment Products User journey driven subdomains change in the system and organizational landscape!
21. THE REAL WORLD - ECOM Landing Search Order Fullfillment Products Landing
22. THE REAL WORLD - ECOM Landing Search Order Products Fullfill ment kafka event bus after five years all domain events and commands on the bus. clear data ownership. The producer is the “truth”. Big Data new consumer can be added fully transparent. big data just consumes everything. Customers Products Searches Orders Fullfillments
23. THE REAL WORLD - ENERGY PROVIDER after 30 years customer information market communications market communications human resources ERP IBM iSeries mainframe application
24. THE REAL WORLD - ENERGY PROVIDER customer information market communications market communications human resources ERP SCS Organizational driven sub domains Next step. Introduction of apache kafka as event bus is planned. Domain events and commands must still be defined Maybe to big as single bounded context or scs. A split is possible and absolut normal
25. CONCLUSION • DDD offers tools and procedures to analyze existing or planned system landscapes. ◦ Bounded Context ◦ Ubiquitous Language ◦ Strategic Design Pattern • domain events und commands define a domain based interaction model between systems. ◦ Asynchron ◦ Synchron • with self contained systems exists an architecture approach which fits very good to DDD ◦ A self contained systems implements a bounded context ◦ One team per self contained system
26. • Bounded Context (Martin Fowler) • Self Contained Systems (InnoQ) LITERATURE
27. ENJOY DIGITAL CHANGE Bonn Am Dickobskreuz 10 53121 Bonn Berlin Kohlfurter Str. 41/43 10999 Berlin Köln Kennedy-Ufer 11 50679 Köln Christian Schmidt Senior Software Engineer IT Consultant c.schmidt@tarent.de @chris__schmidt darktoast christian-schmidt-9644a91b2 Slides at Speaker Deck THANK YOU