Zarządzanie konfiguracją encji z kontekstami ograniczonymi DDD

Question

Próbuję zaimplementować wiele kontekstów ograniczonych przez DDD zgodnie z opisem here. Jest to kontekst przykład:

Mam plik konfiguracji typu jednostki dla każdego podmiotu z odpowiednich przekształceń FluentAPI (reverse zaprojektowane przy użyciu oprzyrządowania EF). Te pliki konfiguracyjne zawierają również konfiguracje relacji.

np .: UserMap.cs

// Relationships 
this.HasOptional(t => t.SecurityProfile) 
    .WithMany(t => t.Users) 
    .HasForeignKey(t => t.SecurityProfileCode); 

SecurityProfile i DomainPermission nie DbSets w kontekście. Są automatycznie wprowadzane do modelu ze względu na właściwości nawigacji odpowiednio na User i Module.

Powoduje to mój pierwszy problem. Podczas dodawania User (lub inny podmiot) na jakimkolwiek innym kontekście muszę pamiętać, aby zrobić jedną z dwóch rzeczy:

1. dodać także konfigurację dla modelu Builder SecurityProfile (i każdy inny związek o podmiocie)

2. Wykluczyć SecurityProfile z modelu jawnie jakoś.

Zaczyna się to troche koszmarnym utrzymaniem.

Byłbym usatysfakcjonowany wyraźnym "obcięciem" wykresu podmiotu, jak opisano w punkcie 2 powyżej.

Jednak nie wydaje się możliwe Ignore() jednostek, gdy relacje są już zdefiniowane w plikach konfiguracyjnych encji.

Próbując modelBuilder.Ignore<SecurityProfile>(); na powyższym kontekście OnModelCreating daje następujący błąd w ConfigureAssociations():

System.InvalidOperationException: właściwość nawigacji „SecurityProfile” nie jest zadeklarowana na właściwość typu „użytkownik”. Sprawdź, czy nie została wyraźnie wykluczona z modelu i czy jest to poprawna właściwość nawigacji.

Jedyne rozwiązanie, jakie mogę wymyślić, to odziedziczyć podstawowe klasy konfiguracji i przesłonić konfigurację relacji w każdym kontekście. Biorąc pod uwagę, że możemy skończyć z 30-40 osobnymi kontekstami, może to również stać się koszmarem dla utrzymania.

Alternatywnie mogłem mieć bardzo konkretne modele jednostek dla każdego kontekstu, ale znowu prowadziłoby to do wybuchu klasy jednostki i potencjalnego problemu konserwacji w zduplikowanej konfiguracji.

Jak najlepiej zarządzać i zarządzać konfiguracjami podmiotów i ich jednostek podczas wdrażania kontekstów ograniczonych?

Answer 1

Dodano tutaj ze względu na zbyt długo za komentarze:

Jest niezwykle (un?) Zabawne, że w artykule do którego się odnosimy jest najwyraźniej próbuje przeskoczyć na modą przez wymienienie nowy buzzword DDD a następnie pokazuje tylko jak obiekty DTO/poco mogą być utrwalone w kontekście. To nie ma absolutnie nic do roboty DDD.

Domain Driven Design to przede wszystkim zachowanie i hermetyzowane modele (izolowane/ignorowane w infrastrukturze), które są iteracyjnie badane i udoskonalane w celu rozwiązania określonych problemów dla konkretnych podmiotów i które są wyrażone w domenie problemowej ubiquitous language.

Modele te zazwyczaj nie map bezpośrednio na pewnego rodzaju modelu trwałości, ani nie powinny być związane z tym. Operacje wykonywane na zagregowanych źródłach w kontekście ograniczonym zazwyczaj będą zgodne z granicami transakcji.

Polecam obejrzeć niektóre z webcastów Eric Evan na temat umiejętności umiejętności (słowo kluczowe DDD eXchange), aby uzyskać właściwą perspektywę tego, co oznacza DDD, jakie są konteksty powiązane i główne źródła. A po tym ty też powinieneś przeczytać jego książkę, to świetna lektura. Ale potrzebujesz jego nowszych perspektyw (wyrażonych w tych webcastach), aby nie wpaść w pułapkę skupiania się na blokach technologicznych.