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.
Hexagonal Architecture + Domain Driven Design. How to perform a correct implementation?
Hello!
Currently, I am trying to implement these two architectures together with Java and Spring (although technology shouldn't matter I think).
But I'm encountering problems getting them to work together.
I understand that my application should have a structure with 3 layers and 2 zones (inside and outside the hexagon):
Domain: Entities that should be self-contained with their own functionality, Repositories, ValueObjects, Factories, Events, etc. This layer is the center of the hexagon.
Application: Where the ports should be found. I've also seen that this is where REST or "input" adapters are typically implemented. This layer is at the edge of the hexagon.
Infrastructure: the implementation of the output ports, where external libraries and frameworks should already be used. This layer is outside the hexagon.
But this raises several questions for me. 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.
Right now I have this structure (after following several guides and reviewing some repositories on GitHub):
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
...
I also have some questions regarding the most appropriate folder structure for this architecture.
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?
Finally. What is the correct naming convention for the different projects and packages?
Thanks in advance!
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