Architecture antipatterns and how to beat them 2/2
summary
Discusses problems caused by trying to keep global ACID transactions across distributed services (the “chronic transaction” antipattern) and gives concrete fixes: publish a business fact atomically when recording an order, send an asynchronous copied order to the warehouse, accept and handle occasional duplicates with compensating actions, and limit a transaction to one aggregate root. Recommends eventual consistency patterns (store events/CQRS or event sourcing), hexagonal architecture (ports-and-adapters) with repository interfaces to invert dependencies, and fast deploys to enable quick healing.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:12Chronic transaction and cure
- 9:49Business vs technical consistency
- 18:28Impest: missing tests
- 22:28Two error types in system
- 27:26Prevention vs fixing errors
- 30:56Test prioritization
- 32:00Layered architecture problems
- 34:33Ports and adapters architecture
- 41:00Permanent mount: module disease
- 44:38Causes of architectural issues
- 47:47Faith in technology
- 48:30Spreadsheet over business
- 51:45Recording facts not state
- 53:15Summary
related talks
52mBreaking Bad Code: From simple problems to complicated solutions and back
08mLightning Talk: Breaking the Mold: Unveiling Anti-Architectural Patterns in...
50mDeveloping Microservices with Aggregates
59mArchitecture Modernization Anti-Patterns: The Cost of Good Intentions
52mEvolving a Pragmatic, Clean Architecture A Craftsman's Guide
48mIT Architecture : All your micro-services are wrong PERIOD!
15mArchitecting Scalable Order Management Systems with Microservices
50mMoving away from CRUD: DDD + CQRS