Kiedy tworzyć ścisłe relacje między encjami (np. one to many itd.) a kiedy opierać się na ich luźnych powiązaniach (np. tylko pole z id)? Załóżmy, że mamy encję User i encję Task. Można to zamodelować tak, że User jest w relacji one to many z Taskiem i ma w sobie listę tych tasków. Wtedy mamy jedno repozytorium User i jeśli chcemy pobrać taski danego Usera, to najpierw z repo pobieramy usera i potem z niego jego taski. Brzmi sensownie, ale pojawiają się pewnie problemy. Jest duży coupling między Userem a Taskiem. User nie potrzebuje przecież Tasków, żeby wykonać na nim jakieś operację biznesowę np. zmiana hasła czy zablokowanie konta. Z pojawianiem się kolejnych encji w jakiś sposób powiązanych z Userem, ten zaczyna puchnąć mając co raz więcej w sobie list do innych encji i metod. User może występować w różnych kontekstach a wiązanie go ściśle z jakaś encją ogranicza go tylko do jednego. Do tego dochodzi problem z wyznaczaniem granic modułów, bo w przypadku ścisłego powiązania taki np Task de facto powinien być podmodułem modułu User a jeśli postawimy na luźniejsze powiązanie, to mogą być to dwa oddzielne moduły komunikujące się tyko potrzebnymi informacjami przez fasady, dto np. czy user istnieje i można do niego dodać taska. Jakie podejście stosujecie?
Może tutaj znajdziesz odpowiedź
https://martinfowler.com/bliki/BoundedContext.html
A co przeszkadza Ci samo stworzenie relacji?
Przecież relacja nie zmusza do pobierania wszystkich informacji z powiązanych encji.
Nadal możesz mieć osobny moduł do tasków i osobny do osób. Jeśli przeszkadza Ci kolumne idPerson w tabeli z taskami to zrób tabelę asocjacyjną i po kłopocie.
Więcej powiem.. Moduł tasków może działać całkowicie niezależnie a każdy task może mieć jako właściciela np.: osobę, firmę, użytkownika ze strony www itp.. itd...
Po to są relacje w relacyjnych bazach danych żeby z nich korzystać. To wprowadza więcej porządku a w dalszej perspektywie ułatwia pracę. Oczywiście można i bez tego ale wówczas pojawiają się inne problemy.
Coś przekombinowałeś....
Przeczytaj najpierw moj stary post: Refactor encji domenowej
TL;DR Tworz minimum relacji miedzy encjami, ktore pozwoli Ci na zachowanie spojnosci modelu w ramach jednej transakcji. Dobrze jest w tym celu wyciagnac tylko tyle danych, ile potrzeba (tzw. granica agregatu, czyli zlepku silnie powiazanych encji).
Wracajac do Twojego konkretnego przypadku. Masz 2 konteksty - operacje zwiazane z kontem uzytkownika (tam
masz encje User) i operacje na zadaniach (tam masz encje Task z user_id). Kazdy kontekst moze miec wlasnego Usera, jesli zajdzie taka potrzeba. Pomysl, czy taki model zapewni Ci mozliwosc sprawdzenia wszystkich warunkow (tzw. niezmienników). Nie przejmuj sie, jesli na jakims widoku musisz pokazac np. szczegoly taska i usera - zrobisz sobie joina :)
Koledzy wyżej już trochę Cię nakierowali na trop, a mianowicie dobrą odpowiedzią na Twoje dylematy jest Domain-Driven Design, a konkretnie koncepcja agregatów. Jest to temat-rzeka i był kilka razy już wałkowany na forum, chociażby:
- DDD - optymalizacja operacji na dużych kolekcjach wchodzących w skład agregatu i paginacja
- Ładowanie agregatów, granice agregatów, encje - kilka pytań
Najlepiej zapoznaj się z tym zagadnieniem bo po części rozwiązuje Twoje problemy.