develop & IT consultant since 2001 > many domains and businesses: banking, payment, insurance, e-commerce, industrial, media, railway, environmental agencies, medical, de-mail, IoT, internet start ups, etc. About me
domain > What are the most important influence factors? > What are suitable approaches and methods? > Context: Distributed applications, Microservices architectures About this talk
Bounded Context A Bounded Context C Conformist User interface Business logic Data storage SCS B User interface Business logic Data storage SCS C User interface Business logic Data storage SCS A Team A Team B Team C Synchronous call Asyncronous call Asyncronous call UI Integration
not only partitions domain model but also defines units for: > development (teams) > deployment > availability > scalability > security zones Context boundary == System boundary
describe relations between domain objects > Be aware of an object’s varying charachteristics in different use cases > Maybe try Event Storming, Alberto Brandolini Domain model
by one person in charge and one team > Concentrate responsibility for business goals / KPIs in one hand > Examples: User registration, eCommerce checkout, conversion rates Process ownership
organization to your system design? > What are the constraints you can‘t change? > Corporate structures > Teams, people and skillsets > … Organizational constraints
Credit Cards Account Statement Credit Offer Interest Credit Contract Credit Line Contact History Settings Standing Order Direct Debit Transaction Installment
additional TAN method > New credit product > New conditions for loans > Changes in legal or supervisory regulations > Reversal of design decisions > Observe potential issues > Number of systems that need to be changed and released for a change > Coordination efforts over several teams Challenge system candidates
system candidate > List quality requirements of each building block > Security (PCI scope?) and data privacy (personal data?) > Time to market, expected release frequency > Availability, max downtime, max recovery time > User groups and UX requirements > Performance, response times, throughput, reads/writes > And other relevant requirements > Quality requirements of system are the sum of their building block‘s requirements Quality requirements
customer experience low Availability high complex, versioned Data model simple, flat few reads/writes Data access many reads monthly Releasing daily System candidate „Credit“ <<use case>> Credit Offering Configuration <<use case>> Credit Sales Process … … Credit expert Customer
e.g.: > Sales processes for credits/loans: Customer, Account, Credit Sales > Probably one owner should be responsible for: > End to end functionality > Consistent, smooth user experience Process ownership
By products: debit, credit, investment, real estate > By sales channels: direct, stationary, brokers, agencies > By customer segments: existing customers, new customers, high-networth, etc. > By any informal structures developed by people or history Organizational aspects
discarded > Reason for discarding > Advantages for current design > Document assumptions, quality requirements and organizational constraints Practical tips
process > Right people: Domain experts, product owners and architects/engineers should work out the system design cooperatively > There are a lot of aspects to consider and trade-offs to be made > The iterative process of challenging and adapting the system design is never finished. Conclusion