u/FooBarBuzzBoom

Am vrut sa-mi caut o cazare in intervalul 22 - 24 mai, adica in weekend si inafara faptului ca nu mai este nicio fucking cazare disponibila, toate au preturi astronomice, efectiv.

Se intampla ceva anume in oras? Btw, daca e cineva care are un apartament liber peste weekend si vrea sa faca un 800 de lei cinsisti, DM me. Efectiv bataie de joc. Cazarile average sar de 2000 de euro, lol.

Doar sa nu mor prost, ce se intampla? Pe Booking si pe Airbnb sunt aceste preturi astronomice. Nu cred ca e un bug, pentru ca ambele platforme sunt afectate.

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!

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!

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!

Salut!

Am inceput sa invat lucruri legate de hexagonal architecture si DDD si am zis sa fac jump-ul de la teorie la concret.

Până acum, am dezvoltat un microserviciu pe care l-am împărțit în layere de: domain, application și infrastructure. Pe partea de domeniu, am creat agregatul împreună cu entitățile și Value Object-urile sale. Din câte am înțeles, porturile ar trebui să fie interfețele care asigură comunicarea cu domeniul, acestea fiind de două tipuri: input (driver) și output (driven), iar usecase-urile ar trebui sa fie niste orchestratori care implementeaza input port-urile si folosesc output port-urile sa faca operatiile posibile end to end, fara sa se amestece in domain logic (am citit despre anemic domain).

O chestiune care mi se pare destul de ciudată este pe partea de porturi de input, unde mulți devs creează câte o interfață separată pentru fiecare operațiune în parte. Înțeleg principiul Interface Segregation, dar o astfel de implementare mi se pare cam extremă. Eu aș prefera să grupez toate operațiunile înrudite într-o singură interfață, la fel cum se procedează în cazul unui controller.

O alta nelămurire este legată de DTO-uri (Data Transfer Objects). În primul rând, o mare parte din validare devine redundantă, deoarece este deja realizată la nivelul entităților /vo-urilor din domeniu. În al doilea rând, mi se pare bizar să nu folosesc Value Object-urile în cadrul DTO-urilor mele. Deși AI-ul mi-a sugerat că acest lucru ar putea genera probleme de serializare, nu văd sensul de a mapa și de a repeta manual toate proprietățile.

Partea de adapters imi este clara, desi nu-s de acord cu definia "implementeaza port-urile", decat pe partea de output. Eu le vad mai mult ca pe pattern-ul Adapter, care face 2 lucruri incompatibile, basically compatibile, translators pentru rest, dbs, etc.

Also, entitatile de infrastructura, ar trebui sa referentieze pur si simplu VO-urile, respectiv entitati de infrastructura, right? Multe lucruri, precum adresele, acum o sa introduca redundancy la nivel de entitate. Cum se procedeaza in acest caz?

Also, la nivel de application, port-urile practic ar trebui grupate dupa domain sau amestecate? La fel si pentru dtos.

Date fiind neconcordantele cu ce citesc prin articole/carti/tutoriale, poate unii din voi aveti experienta mai practica sa-mi spuneti cum ati vazut prin productie scenariile date implementate corect, scalabil.

Multumesc!

Nu am lucrat niciodata cu asa ceva, urmeaza sa incep un nou proiect si-s oleaca ingrijorat de faza cu TDD, iteratii foarte scurte, etc. In echipa curenta, adesea nu ajunge un sprint de 2 saptamani, dar un mini sprint de 1 saptamana!? E placut sa lucrezi cu metodolia asta?