Relacje między encjami a modularność

Czy encje biznesowe powinny być jak najmniej ze sobą powiązane w celu uzyskania jak największej modularności systemu? Załóżmy, że jest sobie jakaś aplikacja do zarządzania kinem. Są encje Film, Screening, i Ticket. W takim tradycyjnym podejściu, to Film miałby listę Screeningów (one to many), Screening miałby Film (many to one) i listę Ticketów (one to many) a Ticket miałby Screening (many to one). Czyli film ma listę seansów, każdy seans ma jeden konkretny film i listę biletów a każdy bilet jest na jakiś jeden konkretny seans. Brzmi sensownie, tylko, że wszystko jest ze sobą ścislę połączone a przecież to chyba mogłby być 3 różne moduły czy nawet mikroserwisy. Czy właśnie w związku z tymi trendami do modularyzacji relacje typu one-to-many i ścisłe łączenie encji ze sobą odchodzi do lamusa?

Sampeteq napisał(a):

Czy encje biznesowe powinny być jak najmniej ze sobą powiązane w celu uzyskania jak największej modularności systemu?

Podchodząc do tematu ogólnie to tak ale jestem wstanie wyobrazić sobie sytuacje kiedy nie ma to sensu a nawet takie kiedy to nie jest wskazane (np. jakieś optymalizacje).
Projektowanie dobrego systemu polega właśnie na tym, żeby nad każdym elementem biznesowym się pochylić, zrozumieć i wywnioskować jak najlepiej reprezentować go w systemie.

Załóżmy, że jest sobie jakaś aplikacja do zarządzania kinem. Są encje Film, Screening, i Ticket. W takim tradycyjnym podejściu, to Film miałby listę Screeningów (one to many), Screening miałby Film (many to one) i listę Ticketów (one to many) a Ticket miałby Screening (many to one). Czyli film ma listę seansów, każdy seans ma jeden konkretny film i listę biletów a każdy bilet jest na jakiś jeden konkretny seans.
Brzmi sensownie, tylko, że wszystko jest ze sobą ścislę połączone a przecież to chyba mogłby być 3 różne moduły czy nawet mikroserwisy.

Gdzie tu masz ścisłe połącznie? Te encje łączy jedynie jakaś relacja. Przecież encja bilet może być tak zaprojektowana, że równie dobrze obsłuży przewozy autokarem, filmy i wejście do ZOO jednocześnie...

Czy właśnie w związku z tymi trendami do modularyzacji relacje typu one-to-many i ścisłe łączenie encji ze sobą odchodzi do lamusa?

Skąd taki wniosek? Reprezentacja danych w bazie danych to tylko jedna strona medalu. Poza tym relacyjne bazy wciąż mają się bardzo dobrze. Mikroserwisy to nieco inne podejście, ogólniejsze i elastyczniejsze - dlatego coraz bardziej popularne. Niestety wydajnościowo w wielu przypadkach się nie sprawdzą i w takich sytuacjach lepszym rozwiązaniem będzie zrobić wszystko na tradycyjnej bazie danych.

Encje musza być ze sobą połączone, bo na tym polega wartość systemu, że wiesz kto kupił bilet na jaki film i który seans. Jeżeli mówimy o przechowywaniu danych relacyjnych, to wręcz teoria mówi o przechowywaniu relacji, a nie danych. Piszesz o relacjach 1-n, jak chcesz je reprezentować nie mając powiązań? Skoro te encje i relacje pomiędzy nimi są modelem rzeczywistości, a system ma tę rzeczywistość odzwierciedlać, to nie da się ich rozerwać. Możesz mniej lub bardziej sztucznie rozdzielać je na usługi, schematy, czy nawet systemy, ale nadal "całość", czyli system rezerwacji i sprzedarzy biletu na konkretny film, o konkretnej godzinie, w konkretnej sali kinowej, z prawem do zajęcia miejsca o jakimś tam numerze, musi posiadać wiedzę o tych powiązaniach.

Sampeteq napisał(a):

Brzmi sensownie, tylko, że wszystko jest ze sobą ścislę połączone a przecież to chyba mogłby być 3 różne moduły czy nawet mikroserwisy. Czy właśnie w związku z tymi trendami do modularyzacji relacje typu one-to-many i ścisłe łączenie encji ze sobą odchodzi do lamusa?

I jaki problem rozwiązałbyś umieszczając tę malutką domenę w 3 różnych modułach/mikroserwisach?

Problem jest taki że mapujesz bezpośrednio encje na tabele w bazie. To wiadomo że Id filmu będzie potrzebne w tabeli screening. ale jest możliwe że:

• będzie potrzebna DTO film bez listy screeningów (zwłaszcza jak screeningi mogą dużo wazyć)
• będzie potrzebna lista DTO screeningów bez filmu (bo no film został już załadowany w innym zapytaniu)

Widać tutaj duże przywiązanie do Hibernate lub jakiegoś innego ORMa
Ja bym wolał bardziej patrzeć jak tych danych będziemy używać w systemie i na podstawie tego używać różnych DTO w zależności od sytuacji. Ale ja od roku żyję w świecie typowanego SQL i functional-relational mapper

Modularyzacja nie polega na tworzeniu mikroserwisu dla każdej tabelki SQLowej. Wręcz przeciwnie, polega na trzymaniu mocno powiązanych koncepcji blisko siebie.