Agregacja względem pola/modelu z innego modułu

0

Czołem,

załóżmy, że mamy aplikację do zarządzania kinem, seansami w nim i sprzedażą biletów na seanse. Sala kinowa, film, seans i bilet są w osobnych modułach - komunikują się DTOsami, a w środku operują na modelach domenowych. Zależności między modułami wyglądają tak:


+--------------+
|              |
|              |
|     Sala     +<-----------------+
|              |                  |
|              |                  |
+--------------+          +-------+---------+           +------------------+
                          |                 |           |                  |
                          |                 |           |                  |
                          |      Seans      +<----------+      Bilet       |
                          |                 |           |                  |
                          |                 |           |                  |
+---------------+         +--------+--------+           +------------------+
|               |                  |
|               |                  |
|     Film      +<-----------------+
|               |
|               |
+---------------+

Przyjmijmy, że bilet oznacza sprzedane miejsce na konkretny seans. Jego model ma w sobie między innymi cenę i ID seansu, natomiast seans ma IDki filmu i sali.
Teraz problem: chcę wyciągnąć spis wszystkich sal i przychody, jakie wygenerowały przez ostatnie X czasu z biletów. Taka operacja wg mnie powinna się znaleźć w module z biletami, ale ten z kolei nic nie wie o istnieniu sal. Jak powinienem to zrobić?

  1. Dodać moduł Sala jako zależność modułu Bilet i wtedy
    a) Dodać ID sali do modelu biletu i wtedy wszystko się staje banalne,
    b) Skoro Bilet wie o Seansach i Salach, wyciągnąć wybrane sale, potem wszystkie seanse które się odbywały w tych salach i są z interesującego mnie przedziału czasu, zliczyć dochód z tych seansów i na podstawie sali przypisanej do seansu policzyć dochód dla każdej sali
  2. Nie dodawać zależności i wykorzystać to, że publiczne DTO seansu zawiera pole z ID sali i na tej podstawie policzyć dochód dla każdego seansu a potem dla każdej sali (rozwiązanie podobne do 1b, ale czy faktycznie wtedy można uznać, że moduł Bilet nie zależy od modułu Sala?)
  3. Olać granice między modułami i napisać SQLa który zrobi wszystko za mnie
    czy może jeszcze inaczej? Może taki podział, jaki zrobiłem, nie ma sensu - jak w takim razie mógłbym taką aplikację podzielić na moduły?
2

A co chcesz osiągnąć przez tak drobno ziarnisty podział na moduły? Stereotypowy podział systemów typu rezerwacja czegoś na moduły(gdzie moduł == bounded context) raczej wygląda w ten sposób na przykładzie kina:

  • crud kina, zarządzanie salami, filmami, seansami
  • obsługa rezerwacji/sprzedaży biletów
  • obsługa płatności
1
neves napisał(a):

A co chcesz osiągnąć przez tak drobno ziarnisty podział na moduły? Stereotypowy podział systemów typu rezerwacja czegoś na moduły(gdzie moduł == bounded context) raczej wygląda w ten sposób na przykładzie kina:

  • crud kina, zarządzanie salami, filmami, seansami
  • obsługa rezerwacji/sprzedaży biletów
  • obsługa płatności

Tak jak Nevas pisze. To są encje, które powinny mieć swój kontekst, i należą do jakiejś dziedziny, możesz je skojarzyć pomiędzy sobą wartościami jak id, cena i tp

Konteskt nie musi być modułem to jest jedynie przestrzeń rozwiązania problemu domeny.

Możesz sobie to wyobrazić tak:

                            Dziedzina Kino
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                                                                           +
+                                                                           +
+   +++++++++++++++++++++++++++++++     ++++++++++++++++++++++++++++++      +
+   +Dziedzina ogólna-pomocnicza  +     +Dziedzina glowna Kino       +      +
+   +Kontest Crud                 +     +Kontest rezerwacji/sprzedaż +      +
+   +++++++++++++++++++++++++++++++     ++++++++++++++++++++++++++++++      +
+                                                                           +
+                                                                           +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Oczywiście jedna dziedzina może mieć wiele kontekstów. Lecz najbardziej pożądane jest, żeby jeden kontekst miał jedną dziedzinę.

0

Dzięki za pomoc, ale nie jestem do końca przekonany do pakowania całego CRUDa w jeden moduł - w tym konkretnym przypadku ma to sens, ale jak do tego podejść, gdy aplikacja zacznie się rozbudowywać? Kontynuując przykład kina - klient może chcieć zarządzać menu (popcorn, cola), promocjami, zniżkami, obsługą kina (etaty, urlopy, godziny pracy) i tak można by wymyślać w nieskończoność. Wtedy (jeśli dobrze rozumiem wasze sugestie) moduł odpowiedzialny za sprzedaż biletów będzie zależał od kodu odpowiedzialnego za zarządzanie pracownikami - tak nie powinno być. Chyba, że podział powinien być poziom wyżej, i wtedy jeden moduł byłby odpowiedzialny za wszystkie sprawy związane z seansami (czyli też: zarządzanie filmami, salami i sprzedaż biletów), inny moduł - za stoisko z jedzeniem, kolejny - za pracowników itd. Każdy z tych modułów miałby swój CRUD, a obok niego jakąś logikę biznesową, która wie o wszystkich encjach w jego obszarze. Co o tym myślicie?

2

Powinieneś myśleć o module jako zestawieniu rzeczy, które ze sobą rozmawiają. Prawidłowo zaprojektowana "paczka" powinna mieć większość klas packageScope albo internal. Nie osiągniesz tego jeśli wszystko ma się ze sobą widzieć.

Jeśli chcesz pobrać coś z innego modułu, to robisz sobie serwis/adapterem w infrastrukturze.

klient może chcieć zarządzać menu (popcorn, cola), promocjami, zniżkami, obsługą kina (etaty, urlopy, godziny pracy)

No do tego jest właśnie kontekst. Dzięki temu popcorn w każdym kontekście będzie odpowiedzialny za coś innego.

W CRUD'ie "Edytorze" będzie miał tylko opis.

W sprzedaży będzie miał dodatkowo cenę i reguły sprzedaży oraz stronę w menu.

W krudzie nie musisz implementować wszystkich elementów kruda dla każdej encji. Tam ma się znaleźć to, co nie ma reguł biznesowych jak teraz opis popcornu, lecz samo tworzenie popcornu widziałbym w kontekście sprzedaży a w krudzie tylko edycje opisu. W sumie nie musisz nawet tego nazywać krudem. W krudzie może się np. znaleźć zakładka kontakt, bo to nie ma żadnych reguł biznesowych.

Poza tym odnoszę wrażenie, że się naczytałeś jakiś metryk projektowania paczek jak ADP, CCP, które mają się nie jak do rzeczywistości. Zgadłem?

1
iksde napisał(a):

Chyba, że podział powinien być poziom wyżej, i wtedy jeden moduł byłby odpowiedzialny za wszystkie sprawy związane z seansami (czyli też: zarządzanie filmami, salami i sprzedaż biletów), inny moduł - za stoisko z jedzeniem, kolejny - za pracowników itd. (...)Co o tym myślicie?

Dokładnie to miałem na myśli, słowo klucz które jeszcze nie padło, to autonomiczność, chcemy by nasze moduły były jak najbardziej niezależne od siebie i by jak najmniej ze sobą rozmawiały. także z tych wszystkich przypadków do tej pory wymienionych ja widzę 5 modułów:

  • crud kina (wszystkie sprawy związane z seansami), zarządzanie salami, filmami, seansami
  • obsługa rezerwacji/sprzedaży biletów
  • obsługa płatności
  • obsługa stoiska z jedzeniem
  • obsługa pracowników

i dokładnie to samo masz w przytoczonej przez Ciebie prezentacji Jakub Nabrdalik w 32 minucie ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1