przypadki użycia to nie klasy a scenariusze

no raczej jest właśnie łatwiej

• wiele adapterów = wiele testów

te adaptery to dostarczone przez ich producentów elementy środowiska, tego używa a nie testuje

”
Przypadki użyciaTo klasy, które obsługują konkretne problemy biznesowe. Jest to faktyzcna wartość dla biznesu, która rozwiązuje ich problem. Przypadki użycia mogą zawierać wszystkie niezbędne walidacje i logikę reguł biznesowych, które są specyficzne dla konkretnego przypadku użycia (dlatego też nie mogą być implementowane w obiektach domeny) a następnie delegują pracę do domeny.”

nie rozumiem do końca podziału przypadków użycia i domeny w tym opisie

rozumiem to tak, że przypadki użycia są wystawionym API z modułu(opisanym jako port wejściowy w Twoim artykule) i one bezpośrednio kierują ruch do domeny, która posiada walidację i logikę reguł biznesowych z racji, że jest domeną, czyli posiada logikę biznesową, u Ciebie robi to klasa Przypadku użycia, co w takim razie znajduje się w domenie?, są to tylko interfejsy? – wnioskuje to z fragmentu „Domena opisuje jak coś zrobić.„

Hej, niestety nie miałem jeszcze okazji wykorzystania jej na produkcji.

Gdybyś szukał linków jak używać/pisać kod w tej architekturze, to te linki mogą być pomocne:

• https://github.com/hirannor/spring-boot-hexagonal-architecture
• https://github.com/thombergs/buckpal
• https://github.com/rdelgatte/spring-hexagonal-architecture
• https://github.com/hexagonframework/hexagonal-architecture-demo

Dzięki za wyjaśnienie architektury Ports & Adapters. Koncepcja nie wydaje się trudna i daje sporo możliwości, ale pewnie trzeba spędzić z nią trochę czasu, aby znaleźć jej ciemne strony 😉 Wykorzystywałeś ją może w jakimś projekcie produkcyjnym?

Pozdrawiam