DDD

• 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 Hexagonal Architecture)
• Onion Architecture
• Clean Architecture

“Ports and Adapters” are simply a better name for Hexagonal Architecture: Hexagonal Architecture. Hexagonal Architecture, which is an improvement over the Traditional Layered Architecture.

Onion Architecture is another name for Hexagonal Architecture (and unfortunate it seems):

We refer to this architecture by the name Hexagonal, even though its name seems to have changed to Ports and Adapters. Despite its changed name, the community still refers to it as Hexagonal. The Onion Architecture has also surfaced. How- ever, it appears to many that Onion is just an (unfortunate) alternate name for Hexagonal. We can safely assume that they are the same and stick with the [Cockburn] definition. (p. 125)

Link to original

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:

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:

The layered architecture is a technically partitioned architecture (as opposed to a domain-partitioned architecture). Groups of components, rather than being grouped by domain (such as customer), are grouped by their technical role in the architecture (such as presentation or business). As a result, any particular business domain is spread throughout all of the layers of the architecture (…). As a result, a domain-driven design approach does not work as well with the layered architecture style.

Link to original