Successfully Decomposing Your Monolith 20190515 DotNext St. Petersburg
•Download as PPTX, PDF•
0 likes•155 views
Designing a system is hard, it’s even harder to build a distributed (microservices) style architecture… Let's try and walk through a simplified example of carving out our bounded contexts and the processes, finding our service boundaries, on the way to building better applications. We will focus on moving from "monolith" to "distributed" thinking, moving from one single entity driven data model to multiple vertical bounded contexts.
Recommended
More Related Content
Similar to Successfully Decomposing Your Monolith 20190515 DotNext St. Petersburg
Similar to Successfully Decomposing Your Monolith 20190515 DotNext St. Petersburg (20)
More from Sean Farmar
More from Sean Farmar (10)
Recently uploaded
Recently uploaded (20)
Successfully Decomposing Your Monolith 20190515 DotNext St. Petersburg
- 1. #DotNextConf @farmar Successfully Decomposing Your Monolith (or UpdateUser(); Means Nothing To Me) Sean Farmar Particular Software 1
- 2. #DotNextConf @farmar Monolith Design Analyse the domain Build a data model that describes the domain Add relationships and dependencies 2
- 3. #DotNextConf @farmar Monolith Design Something like this: 3 Account Id IsClosed OpenDate Customer Id CustomerId Phone Address LineItem Id Quantity Price Order Id OrderNumber OrderDate ShippingDate OrderStatus Id OrderStatusName Payment Id PaymentDate Total Product Id Name Suplier User Id UserName UserStatus Id UserStatusName New Active Blocked Band New Hold Shipped Delivered Closed
- 4. #DotNextConf @farmar Monolith Design Or this: 4
- 5. #DotNextConf @farmar Monolith Design Or this: 5
- 6. #DotNextConf @farmar Monolith Design Add a data layer Add the Business Logic Layer Build the UI … don’t forget the kitchen sink 6
- 8. #DotNextConf @farmar Monolith Design Can we validate the email on registration And then send a welcome email?… Oh, and add some integration with… 8
- 9. #DotNextConf @farmar Monolith Design And soon enough we end up with a big ball of mud… 9
- 10. #DotNextConf @farmar Monolith Design So, do we hack it?? Refactor?? Redesign?? Rewrite?? 10
- 11. #DotNextConf @farmar Monolith Design Do not re-write Decompose… 11
- 12. #DotNextConf @farmar Domain Driven Design DDD 12
- 13. #DotNextConf @farmar Domain Driven Design 13 “Every software program relates to some activity or interest of its user.” Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
- 14. #DotNextConf @farmar Domain Driven Design 14 “DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.” Martin Fowler
- 15. #DotNextConf @farmar DDD Context “The setting in which a work or a statement appears that determines its meaning” Eric Evans 15
- 16. #DotNextConf @farmar DDD Context UpdateUser(User user); A Step in a workflow An Item in a CMS 16
- 17. #DotNextConf @farmar DDD Boundary Inside: Autonomy, Ownership, Context Outside: No direct impact, no side effects, ready for change 17
- 18. #DotNextConf @farmar DDD Bounded Context “The condition under which a particular model is defined and applicable” Eric Evans 18
- 19. #DotNextConf @farmar DDD Bounded Context Where Context and Boundary make it a distinct business process 19
- 20. #DotNextConf @farmar Bounded Context Be explicit, Keep it clean Keep the boundaries Encapsulate 20
- 22. #DotNextConf @farmar Find Units Of Work As a user I can authenticate [UserAuthentication?]: [UserName] (Could be email?) [Password] Does Authorization (access control) belong here as well? 22
- 23. #DotNextConf @farmar Find Units Of Work CustomerContactDetails: [CustomerId] [ContactEmail] (is that the logging email?) [CustomerPhoneNumberId] (optional?) [CustomerAddressId] (optional?) Email and Mobile Validation Process 23
- 24. #DotNextConf @farmar Find Units Of Work CustomerAccount: [UserAuthenticationId] [AccountName] [AccountType] [First Name]? [Last Name]? [AccountActive] 24
- 25. #DotNextConf @farmar Find Units Of Work PaymentDetails: Add one or more payment methods Add Billing Address Add payment methods process(is it a thing?) 25
- 26. #DotNextConf @farmar DDD and Bounded Context Let’s Talk About Process… 26
- 27. #DotNextConf @farmar DDD and Bounded Context It is not going to perfect 27
- 28. #DotNextConf @farmar DDD and Bounded Context 28
- 32. #DotNextConf @farmar CustomerAccount Id UserAuthenticationId AccountName AccountType FirstName LastName AccountActive CustomerAddress Id AddressLine1 AddressLine2 City County Country Zip CustomerBillingAddress Id CustomerId CustomerAddressId Description CustomerContactDetails Id CustomerId CustomerPhoneNumberId CustomerAddressId ContactEmail CustomerPaymentLogs Id CustomerId TransactionId OrderId Ammount CustomerPaymentMethods Id CustomerId PaymentMethodType PaymentDetails IsActive ValidateDate CustomerPhone Id AreaCode PhoneNumber PhoneType CustomerShippingAddress Id CustomerId CustomerAddressId Remarks UserAuthentication Id UserName Password LockedOutDate DDD and Bounded Context 32 UserAuthentication CustomerAccount CustomerPayment CustomerContact
- 33. #DotNextConf @farmar CustomerAccount Id UserAuthenticationId AccountName AccountType FirstName LastName AccountActive CustomerAddress Id AddressLine1 AddressLine2 City County Country Zip CustomerBillingAddress Id CustomerId CustomerAddressId Description CustomerContactDetails Id CustomerId CustomerPhoneNumberId CustomerAddressId ContactEmail CustomerPaymentLogs Id CustomerId TransactionId OrderId Ammount CustomerPaymentMethods Id CustomerId PaymentMethodType PaymentDetails IsActive ValidateDate CustomerPhone Id AreaCode PhoneNumber PhoneType CustomerShippingAddress Id CustomerId CustomerAddressId Remarks UserAuthentication Id UserName Password LockedOutDate DDD and Bounded Context 33 UserAuthentication CustomerAccount CustomerPayment CustomerContact CustomerBilling ?
- 34. #DotNextConf @farmar Work Your Way Up Start in the edge of the system Use APIs where possible Include the data in every iteration 34
- 35. #DotNextConf @farmar Work Your Way Up Find the bounded Context Reduce it to the smallest model you can Find the “Service” Boundaries and it’s processes 35
- 36. #DotNextConf @farmar Work Your Way Up Nothing left outside ITOps – outside service bouderies 36
- 37. #DotNextConf @farmar Domain Driven Design - Bounded Context Loose coupling outside the boundary Tight coupling and cohesion inside the boundary Respect single data ownership 37
- 38. #DotNextConf @farmar Composing UI composition API composition Data composition – Read View Models 38
- 39. #DotNextConf @farmar Summary Use bounded context to slice your verticals Include the data in your vertical slicing Let go of entities, use fields instead 39
- 40. #DotNextConf @farmar Summary Keep your boundaries Reduce coupling between bounded contexts Use asynchronous communication (for state changes) Publish Subscribe between bounded contexts 40
- 41. #DotNextConf @farmar Summary CQS, SRP, Clean Code Align teams, repositories, business segments Don’t forget your stakeholders 41
- 42. #DotNextConf @farmar Summary It won’t be perfect, accept it 42
- 43. #DotNextConf @farmar One more thing Get free access to Advanced Distributed Systems Design course recording with Udi Dahan http://go.particular.net/dotnextru19 43
- 44. #DotNextConf @farmar Thank You! 44 Sean Farmar @farmar Particular.net
Editor's Notes
- Book written by Eric Evens in 2003 Bounded Context is a central pattern in Domain-Driven Design (DDD). It is the focus of DDD's Strategic Design Section which is all about dealing with large models and teams.
- Business/product/user driven development Eric Evens – book written in 2003 Bounded Context is a central pattern in Domain-Driven Design (DDD). It is the focus of DDD's Strategic Design Section which is all about dealing with large models and teams.
- Martin Fowler – International Speaker and Author (Patterns of Enterprise Application Architecture, Refactoring)
- * Information *surrounding* idea which *clarifies meaning*
- If you can imagine a point or limit that indicates where two things become different A boundary is basically what limits us. **Autonomy** ** Coupling **
- Example…An Ecommerce An Account could mean: * User credentials to log into the program – “User Credentials” * A container of money – “Current Business Account” When we try and implement this in software design we should explicitly separate the 2 concepts Another example can be user: One meaning the actual user interacting with the system “Logged In User” And an Account may be a bank account or a user account, To have a Bounded Context you need a model, and an explicit boundary around it. Many data-driven application with shared database lack a boundary
- Stock, wherhouse,