- Tags:: #📝CuratedNotes, [[Software Architecture]]. For the basics, the authoritative source is [[Domain Driven Design]]. ## Confusing layered architecture There is kind of a mess of concepts related to architecture and DDD. There are also many different terms that refer to very similar things. We have: - The [[Traditional Layered Architecture]] proposed in [[Domain Driven Design]] - Hexagonal Architecture. - Ports and Adapters (see [[pages/Hexagonal Architecture]]) - [[Onion Architecture]] - [[Clean architecture]] "Ports and Adapters" are simply a better name for Hexagonal Architecture: [[pages/Hexagonal Architecture]]. [[pages/Hexagonal Architecture]], which is an improvement over the Traditional Layered Architecture. [[Onion Architecture]] is another name for [[pages/Hexagonal Architecture]] (and unfortunate it seems): ![[Implementing domain driven design#^75c616]] [[Clean architecture]] is, once again, based on a similar concept but with a different naming for the layers. ### Criticism to layered architecture These layers don't really match our mental model. Code is organized by function, instead of by business process. It does not match how we develop an application either. [[Jimmy Bogard]] proposed an alternative architecture based on "Vertical Slices" in [Vertical Slice Architecture](https://jimmybogard.com/vertical-slice-architecture/amp/): >When adding or changing a feature in an application, I'm typically touching many different "layers" in an application. I'm changing the user interface, adding fields to models, modifying validation, and so on. Instead of coupling across a layer, we couple vertically along a slice. **Minimize coupling between slices, and maximize coupling in a slice.** With this approach, most abstractions melt away, and we don't need any kind of "shared" layer abstractions like repositories, services, controllers. Sometimes these are still required by our tools (like controllers or ORM units-of-work) but we keep our cross-slice logic sharing to a minimum. It is criticised in [[Fundamentals of Software Architecture. An Engineering Approach]] too: ![[Fundamentals of software architecture. an engineering approach#^b3da8b]]