Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How to break down a Domain to Bounded Contexts

How to break down a Domain to Bounded Contexts

Talk at DDD-Meetup Cologne. Identify and evaluate candidates for Self-contained Systems using DDD and other techniques.

Oliver Tigges

July 17, 2017
Tweet

More Decks by Oliver Tigges

Other Decks in Technology

Transcript

  1. >  Oliver Tigges, @otigges, [email protected] >  innoQ, http://innoQ.com >  Software

    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
  2. >  Goal: Find adequate and sustainable Bounded Contexts in your

    domain >  What are the most important influence factors? >  What are suitable approaches and methods? >  Context: Distributed applications, Microservices architectures About this talk
  3. >  Goal: Independence of systems and teams Design & Implementation

    Releasing & Deployment Runtime & Operations 1 2 3
  4. Customer Account Booking Rating Debit Cards Credit Cards Account Statement

    Credit Offer Credit Contract Credit Line Contact History Settings Standing Order Direct Debit Transaction Installment Credit Sales Context Accounting Context CRM Context Cards Context Interest Account Customer Contract
  5. Messaging Domain Event Subscribe Publish Customer Supplier Bounded Context B

    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
  6. Actually in most projects: >  Software developers & architects Who

    identifies contexts? Alberto Brandolini says: >  Domain experts >  Dev team >  UX experts >  Facilitator
  7. >  If Bounded Context defines the technical system boundaries, it

    not only partitions domain model but also defines units for: >  development (teams) >  deployment >  availability >  scalability >  security zones Context boundary == System boundary
  8. 1.  Domain model: Domain objects and their relations 2.  Use

    Cases, processes and workflows 3.  Quality goals, non-functional requirements 4.  Organizational aspects What to consider?
  9. >  Identify domain objects: events, aggregates, etc. >  Analyze and

    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
  10. >  Identify processes that need to be owned and controlled

    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
  11. >  Derived from business goals >  Examples: >  Time 2

    Market (release/deployment cycles) >  Security >  Availability >  Load and performance (read/write) >  Scalability >  User experience >  … Quality goals
  12. >  Do you have authorization and power to adapt the

    organization to your system design? >  What are the constraints you can‘t change? >  Corporate structures >  Teams, people and skillsets >  … Organizational constraints
  13. >  Like every process in software architecture and development: > 

    Iterative >  Identify system candidates >  Evaluate >  Trade-offs >  Repeat Approach Identify candidates Challenge & Evaluate Trade-Off Decissions
  14. Find initial system candidates Customer Account Booking Rating Debit Cards

    Credit Cards Account Statement Credit Offer Interest Credit Contract Credit Line Contact History Settings Standing Order Direct Debit Transaction Installment
  15. Find initial system candidates Customer Account Booking Rating Debit Cards

    Credit Cards Account Statement Credit Offer Interest Credit Contract Credit Line Contact History Settings Standing Order Direct Debit Transaction Installment Credit Account Customer Cards
  16. >  Looking at the domain model you could identify these

    candidates for Bounded Contexts / systems: Initial candidates Customer Account Cards Credit
  17. >  Typical change scenarios in our example system >  Implement

    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
  18. Scenario Customer Account Cards Credit Change of credit conditions S

    S - L New verification method S L L - Change of external rating agency L - - M New credit product - - - L …
  19. >  Identify main building blocks and use cases of each

    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
  20. ~ 10 Employees/clerks Users > 100,000 Customers functional, experts UI/UX

    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
  21. >  Some processes will span several of identified system candidates,

    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
  22. Customer Account Credit Sales Customer Credit Sales Choose Product Calculate

    Conditions Credit Rating Credit Account (or refusal) Customer data (Sign-Up | Load)
  23. >  System design could/should reflect structures of the organization: > 

    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
  24. Choose Product Calculate Conditions Credit Rating New Customer (or refusal)

    Customer data (Registration) Customer Acquisition Self Care Up Selling Credit Rating New Contract (or refusal) Calculate Conditions Customer Care
  25. >  Record system design decisions: >  Options considered >  Options

    discarded >  Reason for discarding >  Advantages for current design >  Document assumptions, quality requirements and organizational constraints Practical tips
  26. >  Finding sustainable, autonomous SCS can be a long- running

    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