Jak poprawnie wdrożyć współdzielone jądro (DDD) w .Net

Question

Mam starszą aplikację, którą przeprojektowuję, ponieważ w tym miejscu nazywamy ją "kulą błotnistą", w ogóle nie ma warstw ani SOC. Zespół jest przyzwyczajony do pracy modułowej, co oznacza, że ​​istnieje zespół pracujący nad "szkoleniem", "Możliwościami zatrudnienia", który działa na module zarządzającym "Planowaniem służbowym (wojskowym)". Mamy jedną stronę internetową eksponującą te obszary naszym klientom jako portal usług, jedną bazę danych i kilka zewnętrznych aplikacji, które obsługujemy.

Naprawdę dobrze przeprojektowuję większość warstw, z wyjątkiem tego, jak poprawnie podzielić domenę (w tym miejscu powinienem wspomnieć, że używamy .Net 4.0). Początkowo sądziłem, że są to ograniczone konteksty ze względu na sposób, w jaki działali, naprawdę wydawało się, że mają różne grupy użytkowników, ale wierzę, że obecnie ludzie, którzy korzystają z tej strony, mogą i korzystają z wielu obszarów naraz. Oczywiście niektóre grupy WYŁĄCZNIE korzystają z jednej usługi, ale wiele z nich korzysta z kilku. Celem witryny jest kompleksowe zarządzanie "członkami". Pomiędzy modułami mamy klasy unikalne dla tego modułu, a następnie mamy kilka wspólnych klas, na przykład koncepcja elementu jest znana i używana przez wszystkie moduły. Użytkownik jest w rzeczywistości podstawową koncepcją, witryna zwiększa wartość, śledząc informacje o członku we wszystkich tych obszarach jednocześnie. To w zasadzie to, kilka ściśle powiązanych, ale oddzielnych obszarów w systemie i wspólny obszar. Mam nadzieję, że jest to wystarczająco jasne, aby odpowiedzieć na moje pytanie.

Myślę, że nadal miałbym wspólne jądro, nawet jeśli nie są to ograniczone konteksty, dla wspólnych elementów i interfejsów dzielonej domeny, takich jak ogólny interfejs repozytorium. Czy byłoby rozsądnie umieścić cały wspólny kod (ogólne repozytorium, podstawowy model domeny, wspólne jądro itp.) W tej samej przestrzeni nazw lub hierarchii przestrzeni nazw i czy powinienem odizolować tę przestrzeń nazw w swoim własnym zespole? Podobnie, czy mógłbym włamać się do każdego obszaru ("training", "Opportunities" ...) do własnych złożeń, czy lepiej mieć je wszystkie w jednym zespole i logicznie podzielić na partycje według przestrzeni nazw. Z jednej strony nieco łatwiej jest zobaczyć moduły podzielone fizycznie, ale martwię się sytuacjami, w których dwa moduły muszą współpracować, aby rozwiązać problem. Jak mogliby komunikować i utrzymywać rzeczy acykliczne (poprzez usługi w warstwie aplikacji, które zgaduję).

tak (podsumowanie opcji):

Domain.Model (DLL) - Domain.Model.Core - Kernel (wspólny podmiotów i modelu domeny core) - RepositoryFramework - etc. .. - Domain.Model.Training - Domain.Model.Opportunities ...

lub

Domain.Model.Core

Domain.Model.Training (DLL)

Domain.Model.Opportunities (DLL) (jak zrobić trening i możliwości współpracować?)

Dziękuję bardzo za poświęcony czas,

Answer 1

W przypadku fizycznego układu umieściłbym wszystko (cały model domeny) w jednym zestawie. Używanie oddzielnych złożeń nie daje żadnych korzyści, a to komplikuje sytuację i zwiększa czas kompilacji.

Z drugiej strony, jeśli istnieje ryzyko, że niektórzy deweloperzy używają niewłaściwych klas (tych, którzy należą do innego modułu/kontekstu), rozsądne może być podzielenie logiki na wspólny zespół (główna domena, wspólne jądro) i zespoły właściwe dla każdego modułu/kontekstu.

W przypadku układu logicznego (przestrzeni nazw) chciałbym nadać każdej części osobny obszar nazw (na przykład DomainModel.Core, DomainModel.Training). Czasami mądrze jest pójść o krok dalej i umieścić każdy Aggregate we własnej przestrzeni nazw. Zapobiega przypadkowemu przekraczaniu zagregowanych granic, ponieważ wymaga oddzielnej dyrektywy "użytkowej".

Mam nadzieję, że ma to sens.