Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
How can I properly implement Hexagonal Architecture and Domain Driven Design in the same application?
I'm trying to use the "hexagonal architecture" and "domain-driven design" paradigms together, in a Java application using Spring.
I understand that my application should have a structure with 3 layers and 2 zones (inside and outside the hexagon):
-
a domain layer, at the center of the hexagon, for Entities that should be self-contained with their own functionality - such as Repositories, ValueObjects, Factories, Events, etc.
-
an application layer, at the edge of the hexagon, where the ports should be found. I've also seen that this is where REST or "input" adapters are typically implemented.
-
and an infrastructure layer, outside the hexagon, containing the implementation of the output ports, where external libraries and frameworks should already be used.
Based on my research, I have this file layout so far:
Shop (Base Module)
Shop-Domain (Submodule)
src/main/java
├─── net.test.sell.domain
│ └─── error (exceptions related)
│ └─── model (Entities, ValueObjects, Events, etc...)
├─── net.test.workers.domain
....
Shop-Application (Submodule)
src/main/java
├─── net.test.sell.aplication
│ └─── ports
| └─── input (implementation of use cases)
└─── output (interfaces for infrastructure submodule)
│ └─── use_cases (interfaces)
├─── net.test.workers.application
Shop-Infrastructure (Submodule)
src/main/java
├─── net.test.sell.infrastructure
│ └─── database
| └─── adapters (implementation output interfaces)
│ └─── rest_api(interfaces)
| └─── controllers (just REST Controllers)
├─── net.test.workers.infrastructure
...
My questions are:
-
Why are adapters typically implemented in the application layer or in the infrastructure layer, depending on whether they are input or output?
-
What do repositories and domain services do? Shouldn't these be in the application layer as interfaces, and infrastructure should implement them? After all, all the logic should go in the entity.
-
Why do InputPorts use UseCases and OutputPorts are interfaces that are later implemented in infrastructure?
-
Is it a good practice to implement each small UseCase in a separate interface? Or can everything be done in one?
-
What is the correct naming convention for the different projects and packages?
1 answer
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| rudahee | (no comment) | Oct 12, 2024 at 10:14 |
Adapters are implemented in different layers based on their function. Input adapters (like REST controllers) are at the application's edge to handle incoming requests, while output adapters (like databases) are in the infrastructure layer, interacting with external systems.
Repositories and domain services are interfaces in the application layer, implemented in the infrastructure. Entities should handle the core logic, while repositories manage persistence.
For UseCases, it's often clearer to have separate interfaces for each, but you can combine them if they are related. Naming conventions vary, but consistency and clear, descriptive names are key.
Your structure looks well-organized. Stick to clear separation of concerns, and you'll be on the right track.
0 comment threads
0 comment threads