Hexagonal architecture to the edge

[jclaveau]

Hello, and first, thank you for sharing this impressive work.

Hexagonal guidelines I found:

In a speech (in french, sorry) about hexagonal architecture, despite the ports aspect, the architect explains it is a lot about strict separation between the domain and the infrastructure.

• The domain remains the same concept as in simple DDD approach (with ports)
• The infrastructure gathers ALL the rest: db layer, controllers, presenters, framework, libs, application layer (I've seen many different interpretation of what the application is layer and if it belongs to the domain or not but this is not my point here)

The goal of this split is to make the infrastructure interchangeable easily, whenever the product requires a deep evolution of the stack (contrary to the domain which evolves alongside the business). Being able to change the stack having for main goal to avoid being stuck with some parts of it and avoiding producing code dept, obviously.

The speaker explains that, one good way to achieve this is:

• To only have a domain folder and an infrastructure folder at the root of our /src folder https://youtu.be/rjqE3B7nrJk?t=770
• The domain and its base classes must have no direct dependency to the infrastructure (they must be injected by the app)

With your work:

If I want to follow these guidelines using your work, I would need:

• A src/domain package containing my domain abstractions and having as dependencies, your libs/ddd folder (with your guard, exception base class, your decorators and utils).
• Replace the following dependencies by adapters/dependency injection
  • @nestjs/event-emitter and uuid in aggregate-root.base.ts
  • nestjs-request-context and slonik in AppRequestContext.ts
• Split your modules pattern in a domain and an implementation part (infrastructure)

This would allow to have a strictly independent domain using all your conclusions (bridged entity props, guard vs validation, cqrs with correlation/causation...):

• The developing team would be free to change the underlying framework / backend
• The only remaining dependency would be Typescript but I guess this is not a problem :)

My question

• Did you ever heard about this separation and did you consider it?
• Do you think trying an implementation of it would be interesting or a waste of time?

Anyway, thank you for your work and sharing it

[Sairyss]

This project uses The Common Closure Principle (CCP) and Vertical Slice Architecture, meaning related things live close together (respecting the dependency rules between layers, where makes sense). This makes development process easier, since when you modify a feature you have everything you need in the module/feature directory close together and don't need to jump between multiple different places (which gets harder as project grows). I described it briefly in Folder and File Structure and Modules sections. Also check out this video.

Regarding separation into src/domain and src/infrastructure IMO it's not worth it. If you want a clear separation between domain and infrastructure, I would do it inside a module - ModuleName/domain and ModuleName/Infrastructure. This way you keep things close together, and if you need to change the framework, it's not that hard to change it inside every module. You just go through each Module/Infrastructure and change it, it's not that much different than going to src/infrastructure/ModuleName.

In fact, even in current architecture it's not that hard to do. Even though some files live together, layers do not depend on each other (as described here). You could just write a script that goes through every .controller.ts, .repository.ts, etc. files and add an _OLD prefix to each file (or just delete them), and then go reimplement it with the new framework, one by one. This way you'll be working in a context of a module/feature, not in a context of some global Infrastructure. In the end of the day, infrastructure is just a part of a feature, not a separate thing by itself.

You need to decide here what is more important to you: 1.developer experience of keeping things close together, or 2. making swapping framework somewhat easier (but honestly, will you ever need to do that? probably not).

Regarding "infrastructure gathers ALL the rest" - you will at least need to have some separation between input adapters (public interface/API) and output adapters (database access layer, etc). Those two may have totally different frameworks used. If you swap the database, you'll need to change your output adapters, but if you need to swap for example REST to GraphQL you will need to change your input adapters. So I prefer to separate those two.

Replace the following dependencies by adapters/dependency injection

• @nestjs/event-emitter and uuid in aggregate-root.base.ts
• nestjs-request-context and slonik in AppRequestContext.ts

Regarding request context I agree, you could abstract and inject slonik instead of using it directly.

Regarding the aggregate, i'm not sure how you want to do it. You will need to pass event emitter and uuid into aggregate constructor each time you create it, which is not worth it IMO.

You should aim to follow the architecture and domain purity most of the time (when it makes sense), this will make things easier, but trying to get it to 100% by injecting everything is not worth it (as I described here). 100% domain purity comes at a cost not worth paying for most projects, you most likely will never need to swap those frameworks. And even if you do, having 100% pure domain vs 90% pure domain won't make much difference.

[jclaveau]

I'll keep your point in mind. Thank you very much for this fast and really valuable insight!

[quirell]

@Sairyss
Great explaination. This is something that a lot of developers can't wrap their heads around. They seem not to understand the difference between logical and physical (directory layout) separation of layers. Never heard of the common closure principle so it's good to know that it's an established concept, thanks for sharing !