Chapter 2: Wrapping Business Rules inside Domain Hexagon

In the previous chapter, we learned about the Domain as the first hexagon in hexagonal architecture. By being the innermost hexagon, the Domain does not depend on anything above it. Also, we make all the other hexagons depend on the Domain to conduct their operations. This kind of arrangement confers the Domain hexagon a degree of responsibility and relevance far higher than other hexagons. We employ such an arrangement because it is on a domain where we group all the business rules and data that most represent the problem we are trying to solve.

Among the techniques to model a problem domain, Domain Driven Design (DDD) is widely adopted in projects that emphasize software code as a medium to convey knowledge about a business. An always-present concern to separate what constitutes the core problem domain and what is secondary to it makes DDD a suitable approach to support the hexagonal architecture goal to separate technology...