Co należy do korzenia agregatu

Domain-Driven Design: Tackling the Complexity in the Heart of Software ,

Agregat jest zbiorem powiązanych obiektów, które traktujemy jako jednostkę w celu zmiany danych .

Są tu 2 ważne punkty:

1. obiekty te powinny być traktowane jako "jednostka".
2. w celu "zmiany danych".

Wierzę w twój scenariusz, pracownik i naruszenie nie są koniecznie jednostki razem, natomiast w przykładzie Order i OrderItem, są one częścią jednej jednostki.

Inną rzeczą, która jest ważna podczas modelowania granic aggregate, jest to, czy masz jakieś niezmienniki w swoim agregacie. Niezmienniki to reguły biznesowe, które powinny obowiązywać w ramach" całego " agregatu. Na przykład, jeśli chodzi o Przykład Order i OrderItem, możesz mieć niezmiennik, który mówi, że całkowity koszt zamówienia powinien być mniejszy niż predefiniowana kwota. W tym w przypadku, gdy chcesz dodać OrderItem do zamówienia, ten niezmiennik powinien być egzekwowany, aby upewnić się, że Twoje zamówienie jest ważne. Jednak w Twoim problemie nie widzę żadnych niezmienników między twoimi bytami: pracownik i naruszenie.

Tak krótka odpowiedź:

Uważam, że każdy pracownik i naruszenie należą do 2 oddzielnych agregatów. Każdy z tych Bytów jest także ich własnym zagregowanym korzeniem. Potrzebujesz więc 2 repozytoriów: EmployeeRepository i ViolationRepository.

Ja również uważam, że powinieneś mieć jednokierunkowy związek od naruszenia do pracownika. W ten sposób każdy obiekt naruszenia wie, do kogo należy. Ale jeśli chcesz uzyskać listę wszystkich naruszeń dla konkretnego pracownika, możesz zapytać ViolationRepository:

var list = repository.FindAllViolationsByEmployee(someEmployee);

Mówisz, że masz podmiot pracowniczy i naruszenia, a każde naruszenie nie ma żadnego zachowania. Z tego co mogę przeczytać powyżej, wydaje mi się, że możesz mieć dwa zagregowane korzenie:

• pracownik
• EmployeeViolations (nazwij to EmployeeViolationCard lub EmployeeViolationRecords)

EmployeeViolations jest identyfikowany za pomocą tego samego identyfikatora pracowniczego i przechowuje zbiór przedmiotów naruszenia. Zachowanie pracownika i naruszenia są rozdzielone w ten sposób i nie dostajesz naruszenia bez zachowania.

Czy naruszenie jest encją czy obiektem wartości, należy zdecydować na podstawie jego właściwości.

Generalnie zgadzam się z Moshem w tej kwestii. Należy jednak pamiętać o pojęciu transakcji z punktu widzenia biznesu. Tak więc "w celu zmiany danych" Rozumiem "w celu transakcji(transakcji)".

Repozytoria są widokami modelu domeny. W środowisku domenowym te "widoki" naprawdę wspierają lub reprezentują funkcję lub zdolność biznesową - transakcję. Przypadku, pracownik może mieć jedno lub więcej naruszeń, a jeśli tak, są aspekty transakcja(transakcje) w danym momencie. Rozważ swoje przypadki użycia.

Scenariusz: "pracownik popełnia czyn, który jest naruszeniem miejsca pracy."Jest to rodzaj zdarzenia biznesowego (tj. transakcja lub część większej, być może rozproszonej transakcji), które miało miejsce. Obiekt domeny dotkniętej rootem rzeczywiście można zobaczyć z więcej niż jednej perspektywy, dlatego jest to mylące. Ale rzeczą do zapamiętania jest zachowanie, ponieważ odnosi się do transakcji biznesowych, ponieważ chcesz swój biznes procesy, aby modelować świat rzeczywisty tak dokładnie, jak to możliwe. Jeśli chodzi o relacje, podobnie jak w relacyjnej bazie danych, twój konceptualny model domeny powinien już o tym wskazywać( np. asocjacyjność), co często można odczytać w obu kierunkach:

Pracownik naruszenie

Więc w tym przypadku użycia, byłoby sprawiedliwe, aby powiedzieć, że jest to transakcja zajmująca się naruszeniami, i że główny-lub" główny " podmiot-jest Naruszenie. To będzie twój zagregowany korzeń, który odwołasz się do tej konkretnej działalności biznesowej lub procesu biznesowego. Ale nie oznacza to, że dla innej działalności lub procesu nie można mieć korzenia Agregującego pracownika, takiego jak "nowy proces pracownika". Jeśli zachowasz ostrożność, nie powinno być negatywnego wpływu cyklicznych odniesień lub możliwości przechodzenia modelu domeny na wiele sposobów. Ostrzegam jednak, że rządzenie tym powinno być przemyślane i obsługiwane przez część kontrolera Twojej domeny biznesowej lub jakikolwiek jej odpowiednik.

Pomijając: myśląc w kategoriach wzorców (np. MVC), repozytorium jest widokiem, obiekty domeny są modelem, a zatem należy również zastosować jakąś formę wzorca kontrolera. Zazwyczaj kontroler deklaruje konkretną realizację i dostęp do repozytoriów (zbiorów zagregowanych korzeni).

W świecie dostępu do danych...

Używając LINQ-to-SQL jako przykładu, DataContext będzie kontrolerem wyświetlającym Widok klientów i podmiotów zamawiających. Widok jest nieeklaratywnym, zorientowanym na framework typem tabeli (przybliżony odpowiednik repozytorium). Zauważ, że widok zachowuje odniesienie do kontrolera nadrzędnego i często przechodzi przez kontroler, aby kontrolować, jak / kiedy Widok zostanie zmaterializowany. Tak więc Sterownik jest Twoim dostawcą, dbając o mapowanie, tłumaczenie, nawodnienie obiektów itp. Model jest wtedy Twoje dane POCOs. Raczej typowy MVC wzór.

Używając N / Hibernate jako przykładu, ISession będzie kontrolerem odsłaniającym Widok klientów i zleceń poprzez sesję.Enumerable (string query) lub session.Get (object id) lub session.CreateCriteria (typeof(Klient)).List ()

Customer { /*...*/ }

Employee { /*...*/ }

Repository<T> : IRepository<T>
              , IEnumerable<T>
              //, IQueryable<T>, IQueryProvider //optional

{ /**/ }

BusinessController {
 Repository<Customer>  Customers { get{ /*...*/ }} //aggregate root
 Repository<Order> Orders { get{ /*...*/ }} // aggregate root
}

W skrócie, pozwól procesom biznesowym i transakcjom być przewodnikiem, a twoja Infrastruktura biznesowa naturalnie ewoluuje w miarę wdrażania procesów/działań lub refakturowane. Co więcej, preferuj kompozytowość w porównaniu z tradycyjnym wzornictwem czarnej skrzynki. Kiedy dojdziesz do usług zorientowanych lub cloud computing, będziesz zadowolony, że to zrobiłeś. :)

Zastanawiałem się, jaki byłby wniosek?

'naruszenia' stają się istotą root. A "naruszenia" byłyby przywoływane przez "pracowniczą" jednostkę root. repozytorium naruszeń ie repozytorium pracowników

Ale jesteś przekonany o tym, że naruszenia są istotą root, ponieważ nie mają żadnego zachowania.

Ale czy "zachowanie" jest kryterium kwalifikującym się jako podmiot root? Nie sądzę.

Lekko ortogonalne pytanie, aby sprawdzić zrozumienie tutaj, wracając do porządku...Przykład OrderItem, może być moduł analityczny w systemie, który chce spojrzeć na OrderItems bezpośrednio tj. uzyskać wszystkie orderItems dla danego produktu lub wszystkie pozycje zamówienia większe niż jakaś podana wartość itp., czy mając wiele takich przypadków użycia i prowadząc "agregatowy korzeń" do ekstremum, czy moglibyśmy argumentować, że OrderItem jest innym zbiorczym korzeniem samym w sobie ??

To zależy. Czy jakakolwiek zmiana/dodanie / usunięcie wioation zmienia jakąkolwiek część pracownika - np. czy przechowujesz liczbę naruszeń lub liczbę naruszeń w ciągu ostatnich 3 lat przeciwko pracownikowi?