Autonomous Bounded Contexts
•Download as PPTX, PDF•
0 likes•113 views
هادی احمدی در این سخنرانی به اشتباهات رایج در یکپارچهسازی #BC (#BoundedContext) ها و عواملی که باعث وابستگی BC ها به یکدیگر و از بین رفتن استقلال آنها می شود، میپردازد.
Recommended
Recommended
More Related Content
Similar to Autonomous Bounded Contexts
Similar to Autonomous Bounded Contexts (20)
More from Iranian Domain-Driven Design Community
More from Iranian Domain-Driven Design Community (10)
Recently uploaded
Recently uploaded (20)
Autonomous Bounded Contexts
- 1. Moving Toward Autonomy HAhmadi15 Hadi Ahmadi Ahmadi.hadi@outlook.com
- 2. Blazing Fast
- 4. Distributed Monolith You have all the difficulties of a distributed System And you still have the problems of a Monolith
- 6. 6 Coupled to implementation details 40% Database Integration Tied to a specific technology Low Cohesion
- 7. Avoid database integration at all costs
- 9. 9 DRY Principle "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system"
- 10. 10 Impractical in big enterprises DRY Principle Needs high level of communication Coupling between BCs are far worse than code duplication
- 11. 11
- 12. 12 Sync & Pull-Based Communications Auction I want to place a bid Parties Has her account been approved? Yes ! Done !
- 13. 13 Async & Push-Based Communications Auction I want to place a bid Parties Someone has been confirmedDone !
- 14. 14 Pull vs Push Auction Parties Has her account been approved? Yes ! Auction PartiesSomeone has been confirmed Optimize for AutonomyOptimize for Authority
- 15. 15 Orchestration-Based Saga Sales Create a customer LoyaltyInitial Balance NotificationSend Welcome
- 16. 16 Orchestration-Based Saga Central governing authority Can Result in “god” services
- 17. 17 Choreography-Based Saga Sales Create a customer Loyalty NotificationCustomer Created Publish Subscribe Subscribe
- 18. 18 Choreography-Based Saga Significantly more decoupled more flexible easy to change
- 20. 20 Micro Frontends "An architectural style where independently deliverable frontend applications are composed into a greater whole" Micro Frontend A Micro Frontend B Micro Frontend C A B C
- 21. 21 Micro Frontends Autonomous teams Independent deployment decoupled codebases
- 22. 22 Gigantic, Shared Read Models Sales Inventory Shipping Read Model Read Database Projections Update
- 24. 24 Wrong Versioning Strategies InventoryClient POST Api/v2/InventoryTransactions Client POST Api/v1/InventoryTransactions
- 25. 25 Versioning Strategies Avoid making Breaking Changes Defer breaking changes as Long as Possible Use Tolerant Readers Wisely Choose Your Versioning Strategy
- 26. 26 Coupling To Internal Process of BCs Sales Order Initiated Fulfilment Order Item AddedOrder Item Added Order Placed Start Fulfilment Process { OrderId : 1 }
- 27. 27 Coupled Clients Server Client GET Api/Orders/1/Items 200 OK POST Api/Orders 200 OK
- 28. Hypermedia As The Engine Of Application State
- 29. Thank You
Editor's Notes
- First, we are allowing external parties to view and bind to internal implementation details. I have to be extremely careful that I don’t break parts of the schema used by other services. (Hiding Implementation Details) Second, my consumers are tied to a specific technology choice . (Loose Coupling) If the warehouse, registration UI, and call center UI all need to edit customer information, I need to fix a bug or change the behavior in three different places, and deploy those changes too . (Cohesion)
- First, we are allowing external parties to view and bind to internal implementation details. I have to be extremely careful that I don’t break parts of the schema used by other services. (Hiding Implementation Details) Second, my consumers are tied to a specific technology choice . (Loose Coupling) If the warehouse, registration UI, and call center UI all need to edit customer information, I need to fix a bug or change the behavior in three different places, and deploy those changes too . (Cohesion)
- First, we are allowing external parties to view and bind to internal implementation details. I have to be extremely careful that I don’t break parts of the schema used by other services. (Hiding Implementation Details) Second, my consumers are tied to a specific technology choice . (Loose Coupling) If the warehouse, registration UI, and call center UI all need to edit customer information, I need to fix a bug or change the behavior in three different places, and deploy those changes too . (Cohesion)
- DRY is what leads us to create code that can be reused. We pull duplicated code into abstractions that we can then call from multiple places.
- The downside to this orchestration approach is that the customer service can become too much of a central governing authority. Can result in a small number of smart “god” services telling anemic CRUD-based services what to do. You do need to do extra work to monitor and track the processes across system boundaries, however. systems that tend more toward the choreographed approach are more loosely coupled, and are more flexible and amenable to change.
- The downside to this orchestration approach is that the customer service can become too much of a central governing authority. Can result in a small number of smart “god” services telling anemic CRUD-based services what to do. You do need to do extra work to monitor and track the processes across system boundaries, however. systems that tend more toward the choreographed approach are more loosely coupled, and are more flexible and amenable to change.
- The downside to this orchestration approach is that the customer service can become too much of a central governing authority. Can result in a small number of smart “god” services telling anemic CRUD-based services what to do. You do need to do extra work to monitor and track the processes across system boundaries, however. systems that tend more toward the choreographed approach are more loosely coupled, and are more flexible and amenable to change.
- The downside to this orchestration approach is that the customer service can become too much of a central governing authority. Can result in a small number of smart “god” services telling anemic CRUD-based services what to do. You do need to do extra work to monitor and track the processes across system boundaries, however. systems that tend more toward the choreographed approach are more loosely coupled, and are more flexible and amenable to change.
- The downside to this orchestration approach is that the customer service can become too much of a central governing authority. Can result in a small number of smart “god” services telling anemic CRUD-based services what to do. You do need to do extra work to monitor and track the processes across system boundaries, however. systems that tend more toward the choreographed approach are more loosely coupled, and are more flexible and amenable to change.
- Avoid breaking changes and the need to version by understanding Postel’s Law and using tolerant readers.
- Avoid breaking changes and the need to version by understanding Postel’s Law and using tolerant readers.
- The downside to this orchestration approach is that the customer service can become too much of a central governing authority. Can result in a small number of smart “god” services telling anemic CRUD-based services what to do. You do need to do extra work to monitor and track the processes across system boundaries, however. systems that tend more toward the choreographed approach are more loosely coupled, and are more flexible and amenable to change.
- scaling frontend development so that many teams can work simultaneously on a large and complex product is even harder.