Architecture antipatterns and how to beat them 1/2
summary
Describes common architecture antipatterns in domain-rich business systems—especially a single bloated domain model and an anemic domain—and concrete fixes using Domain-Driven Design and CQRS. Recommends splitting by bounded contexts so identities become multiple precise types, moving behavior into domain objects instead of using getters, and separating read/write models (CQRS) to keep views lightweight; gives examples like a swollen User entity and a mailer invoked inside a Spring @Transactional rollback hazard that can abort order creation when email fails.
AI-written summary · about
chapters (6)
- 0:00Wprowadzenie i metafora systemów
- 7:20Modelio – choroba spuchniętych encji
- 18:07Anemiczny model – pułapka geterów i seterów
- 22:41Odczyt vs zapis – problem jednego modelu
- 30:19CQRS – oddzielanie odczytów od zapisów
- 36:25Przewlekła transza – niebezpieczna pułapka
related talks
48mDomain Pattern – How the Domain Influences the Architecture
59mDomain-Driven Design - Where Rubber Meets the Road
45mDon't Overdose on Domain-Driven Design
52mEvolving a Pragmatic, Clean Architecture A Craftsman's Guide
55mBack to the Basics. Modeling Our Domain
50mMoving away from CRUD: DDD + CQRS
36mApplication Architecture Patterns
55mDomain-Driven Design: back to the roots