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.

Review Suggested Edit

You can't approve or reject suggested edits because you haven't yet earned the Edit Posts ability.

~~Hexagonal Architecture + Domain Driven Design. How to perform a correct implementation?~~

How can I properly implement Hexagonal Architecture and Domain Driven Design in the same application?

~~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!~~

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.
<details><summary>Based on my research, I have this file layout so far:</summary>
```
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
...
```
</details>
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?

java spring tools architecture domain-driven-design

java spring hexagonal-architecture domain-driven-design

Communities

Review Suggested Edit