CRUD - "Package by feature" zamiast "Package by layer"

Obejrzałem sobie ten wykład
Podoba mi się podejście do pakietu jako do hermetycznego komponentu z pojedynczym interfejsem dostępu w postaci fasady, ale po długim używaniu podejścia package by layer(pakiety typu: controller, service, entity, repository) czegoś nie rozumiem. Mianowicie relacji między encjami bazodanowymi.
W prezentacji ukazany jest przykład takiego feature'a

Z tego co rozumiem Article jest klasą mapowaną na encję bazodanową. W klasycznym podejściu warstwowym, gdzie wszystkie encje są publiczne prawdopodobnie Article by wyglądało mniej więcej tak (Hibernate):

@Entity
public class Article {
	@Id 
	Long id;
	String title;
	String content;
	// jakies inne kolumny...

	@OneToOne
	Category category;

	@OneToOne
	User author;

	@OneToMany
	List<Tag> tags;
}

klasy Category, User, Tag to również encje w rozumieniu bazy danych.

Jednak w momencie, gdy dzielimy kod na zamknięte pakiety, a encje są schowane przed dostępem spoza pakietu sprawa się komplikuje. Tworząc encję Article nie mam dostępu do encji Category, User, Tag. Przecież są ukryte w swoich pakietach... A tworząc pakiet "entities" z publicznymi encjami tracimy w zasadzie wszystkie plusy architektury package by feature.
Tak jak encje Category lub Tag można by jeszcze umieścić pod domeną "article", to User jest encją uniwersalną i raczej wykorzystywaną w innych miejscach systemu i raczej będzie miał swój własny pakiet "user". Stąd 2 pytanka:

1. W jaki sposób rozwiązuje się taki problem w tego typu architekturach? Czy rezygnujemy całkowicie z kluczy obcych i dobrodziejstw ORMa, przechowując np. id Usera/Kategorii, a gdy potrzebujemy się do ich informacji dostać używamy UserFacade.findByName(article.getAuthorName())?

@Entity
public class Article {
	// ...

	@OneToOne
	Long categoryId;

	@OneToOne
	String authorName;
}

1. Czy znacie jakieś open source projekty, w których używana byłaby tego typu architektura? Koniecznie żeby to był w miarę dojrzały projekt, a nie jakiś hello world z dwoma pakietami. Chciałbym zobaczyć jak się rozwiązuje problemy tej architektury na żywym organizmie. Najlepiej gdyby projekt był w stacku Spring+Hibernate.

1. No ja mam nadzieje że to nie jest żadne hibernatowe entity, tylko zwykły obiekt domenowy
2. Jeśli koniecznie potrzebujesz to zrób osobny moduł db albo persistence i tam wrzuć sobie translacje obiektów domenowych do jakiegoś persistent data storage
3. Poza tym ten przykład nie ma sensu, bo przecież te wszystkie elementy są częścia tej samej funkcjonalności i tego samego modelu, nie wiem skąd pomysł żeby nagle jakiś Tag pchać do innego modułu czy w ogóle innego serwisu.

Odpowiedź jest prosta - nie masz referencji bezpośrednio z Article do Category tylko w Article trzymasz jedynie categoryId. W tenże sposób wszystkie klasy mogą być z dostępem pakietowym. Owszem, zmienia to podejście przy projektowaniu modułów klas, ale nie ma opcji by Article mógł cokolwiek grzebnąc w Category - bedzie mógł to zrobić jedynie przez fasady podając categoryId (mam tu na mysli operacje na kategorii, a nie maniuplacje kategoriami w artykule, czyli np. zmiana nazwy kategorii).

Co do projektów to od razu powiem, że jest cięzko żeby znaleźć projekt, w którym sensownie jest zrobiona komunikacja miedzy modułami, a sam projekt rzeczywiście coś robi, ale pewnie coś by się znalazło jednak jeżeli chcesz żeby to było na Hibernate to raczej nic takiego nie znajdziesz, przy takim podejściu ORM nic nie daje

Grzyboo napisał(a):

1. W jaki sposób rozwiązuje się taki problem w tego typu architekturach? Czy rezygnujemy całkowicie z kluczy obcych i dobrodziejstw ORMa, przechowując np. id Usera/Kategorii, a gdy potrzebujemy się do ich informacji dostać używamy UserFacade.findByName(article.getAuthorName())?

Witaj w świecie podziału wertykalnego :), tutaj nie jest już tak prosto jak w świecie podziału horyzontalnego gdzie bezmyślnie grupuje się klasy po roli jaką spełniają w systemie. To co chcemy osiągnąć to jak największa autonomiczność poszczególnych kawałków. Bez względu na to czy robimy modularny monolit podzielony by feature/by component, czy robimy soa/mikroserwisy, myślenie jest podobne. Projektujemy system tak jakby każdy kawałek miał własne źródło danych, nawet jak pod spodem jest jedna i ta sama baz danych. A skoro każdy kawałek ma (teoretycznie) osobne źródło danych jakiekolwiek klucze obce pomiędzy źródłami danych odpadają (pozostają czyste idki czy też guidy)

W jedynym kawałku potrzebujemy danych z innego kawałka, jakie mamy opcje:

1. odpytujemy ten drugi kawałek za pomocą jego publicznego interfejsu UserFacade.findById(article.getAuthorId())
2. dostajemy potrzebne dane z warstwy wyżej która orkiestruje działanie systemu, w przypadku podziału by feature -> UI, w przypadku podziału by component -> contoler
3. jeśli tych danych do przesyłania jest dużo, to zamiast je przesyłać trzyma się ich kopie w tym kawałku który je potrzebuje, albo to oznacza że źle podzieliliśmy system na kawałki (zbyt cienkie)

Grzyboo napisał(a):

Tak jak encje Category lub Tag można by jeszcze umieścić pod domeną "article", to User jest encją uniwersalną i raczej wykorzystywaną w innych miejscach systemu i raczej będzie miał swój własny pakiet "user". Stąd 2 pytanka:

Raczej odwrotnie bym to widział, każdy pakiet by miał własnego użytkownika, o ile oczywiście by potrzebował coś więcej niż jego id.

Najważniejszym i najtrudniejszym pytaniem jest to jak szerokie powinny być nasze kawałki, na pewno nie powinny zawierać pojedynczych encji bo wtedy prawie nic nie zyskujemy. Najlepsza odpowiedzią jaką do tej pory znalazłem na to pytanie, jest to że kawałek == bouded context z DDD.

Nawet bardziej niż bounded context pasuje tu:

Agregat