DDD & Hexagonal Architecture Dilemma Hey! I’ve started…
0 reactions
DDD & Hexagonal Architecture Dilemma
Hey! I’ve started learning about Hexagonal Architecture and DDD, and I decided to make the jump from theory to practice.
So far, I’ve developed a microservice that I split into three layers: *domain*, *application*, and *infrastructure*. On the domain side, I created the aggregate along with its entities and Value Objects. From what I understand, ports should be the interfaces that handle communication with the domain, and they come in two types: *input* (driver) and *output* (driven). Use cases are supposed to act as orchestrators that implement the input ports and use the output ports to make operations possible *end-to-end*, without messing with the *domain logic* (I've read about the *anemic domain model*).
One thing that seems quite strange to me is on the input ports side, where many devs create a separate interface for every single operation. I understand the *Interface Segregation Principle*, but this kind of implementation feels a bit extreme. I would prefer to group all related operations into a single interface, much like you would do in a controller.
Another point of confusion is related to DTOs (*Data Transfer Objects*). First of all, a lot of the validation becomes redundant since it's already handled at the domain entity/VO level. Secondly, it feels bizarre not to use Value Objects inside my DTOs. Even though the AI suggested this could cause serialization issues, I don't see the point of just throwing properties in there and repeating everything manually.
The *adapters* part makes sense to me, though I don’t agree with the definition "implements the ports", except on the output side. On the input side, I see them more as the *Adapter* pattern, which basically makes two incompatible things compatible, acting as *translators* for REST, DBs, etc.
Also, should infrastructure entities simply reference VOs and other infrastructure entities, right? A lot of things, like addresses, are going to introduce redundancy at the entity level now. How is this usually handled?
Also, at the application layer, should ports practically be grouped by domain or mixed together? Same question for DTOs.
Given the discrepancies with what I read in articles/books/tutorials, maybe some of you have more practical experience and can tell me how you’ve seen these scenarios implemented correctly and scalably in production.
Thanks!
#dev #programming #technology
source
Hey! I’ve started learning about Hexagonal Architecture and DDD, and I decided to make the jump from theory to practice.
So far, I’ve developed a microservice that I split into three layers: *domain*, *application*, and *infrastructure*. On the domain side, I created the aggregate along with its entities and Value Objects. From what I understand, ports should be the interfaces that handle communication with the domain, and they come in two types: *input* (driver) and *output* (driven). Use cases are supposed to act as orchestrators that implement the input ports and use the output ports to make operations possible *end-to-end*, without messing with the *domain logic* (I've read about the *anemic domain model*).
One thing that seems quite strange to me is on the input ports side, where many devs create a separate interface for every single operation. I understand the *Interface Segregation Principle*, but this kind of implementation feels a bit extreme. I would prefer to group all related operations into a single interface, much like you would do in a controller.
Another point of confusion is related to DTOs (*Data Transfer Objects*). First of all, a lot of the validation becomes redundant since it's already handled at the domain entity/VO level. Secondly, it feels bizarre not to use Value Objects inside my DTOs. Even though the AI suggested this could cause serialization issues, I don't see the point of just throwing properties in there and repeating everything manually.
The *adapters* part makes sense to me, though I don’t agree with the definition "implements the ports", except on the output side. On the input side, I see them more as the *Adapter* pattern, which basically makes two incompatible things compatible, acting as *translators* for REST, DBs, etc.
Also, should infrastructure entities simply reference VOs and other infrastructure entities, right? A lot of things, like addresses, are going to introduce redundancy at the entity level now. How is this usually handled?
Also, at the application layer, should ports practically be grouped by domain or mixed together? Same question for DTOs.
Given the discrepancies with what I read in articles/books/tutorials, maybe some of you have more practical experience and can tell me how you’ve seen these scenarios implemented correctly and scalably in production.
Thanks!
#dev #programming #technology
source
| 0 mlx | |
| 3 | |
| 0 |