DDD, a podejście Code First - jeden model czy osobne?

Mam pewien model domenowy. Czy mogę go użyć w podejściu code first, czy lepiej pozostawić "czysty" bez żadnych zależności bazodanowych i zrobić do tego drugi?
Rozważany uproszczony model:

public class Schedule
    {
        public int Id { get; protected set; }
        public string Name { get; protected set; }
        public DateTime Date { get; protected set; }
        private ISet<ScheduleEvent> _events = new HashSet<ScheduleEvent>();
        public IEnumerable<ScheduleEvent> Events 
        { 
            get => _events;
            protected set => _events = new HashSet<ScheduleEvent>(value); 
        }

        protected Schedule() { }

        public Schedule(string name)
        {
            Name = name;
            Date = DateTime.UtcNow;
        }

        public void Update()
        {
            Date = DateTime.UtcNow;
        }
    }

Jak to ugryźć, lepiej zrobić drugi ScheduleEntity czy działać na samym Schedule?

Cały model to jedna klasa? To chyba nie ma sensu bawić się w DDD. Nie wiem też, czy jest sens używać ORMa do tego. W ogóle nie wiem czy jest sens.

W ogólnym przypadku, to jeśli Twój model miałby mieć jakieś zależności od ORMa, to to nie będzie już model domeny, a więc trudno mówić o DDD. EF chyba wciąż nakłada na programistę szereg wymagań odnośnie tworzenia klas mapowanych na bazę, więc stosując ten ORM nie da się osiągnąć persistence ignorance. Oddzielny model składowania może być rozwiązaniem tego problemu. Alternatywy to zmiana ORMa na inny albo olanie DDD.

Wszystko zalezy od tego czy w Twoim konkretnym przypadku uzywanie tej samej klasy wymagalo by wprowadzenia jakichs zaleznosc miedzy domena a warstwa perzystencji. Jesli takich zaleznosci nie ma, i uzywana implementacja perzystencji (w tym przypadku EF) nie wplywa na "wyglad" modelu to nie ma potrzeby wprowadzac dodatkowego modelu do mapowania z baza.

somekind napisał(a):

EF chyba wciąż nakłada na programistę szereg wymagań odnośnie tworzenia klas mapowanych na bazę, więc stosując ten ORM nie da się osiągnąć persistence ignorance. (...) Alternatywy to zmiana ORMa na inny albo olanie DDD.

Bzdura, szczegolnie jesli mowa o EF Core. To juz NHibernate naklada wiecej wymagan. W EF Core 2.1 w zasadzie ciezko znalezc jakies "wymagania" co do tego jak ma wygladac POCO. No chyba tylko w przypadku wprowadzania many-to-many.

stosując ten ORM nie da się osiągnąć persistence ignorance. Oddzielny model składowania może być rozwiązaniem tego problemu. Alternatywy to zmiana ORMa na inny albo olanie DDD.

Odnośnie do tej alternatywy to zabrzmiało jak byś namawiał do tego aby niestosować oddzielnego modelu dla Persistence z Domain Modelem. Czy ja dobrze rozumiem.?

Wszystko zalezy od tego czy w Twoim konkretnym przypadku uzywanie tej samej klasy wymagalo by wprowadzenia jakichs zaleznosc miedzy domena a warstwa perzystencji. Jesli takich zaleznosci nie ma, i uzywana implementacja perzystencji (w tym przypadku EF) nie wplywa na "wyglad" modelu to nie ma potrzeby wprowadzac dodatkowego modelu do mapowania z baza.

Tak, ale nie ma co czarować, wtedy to nie jest żaden model domeny tylko model bazodanowy a dokładniej jest to struktura dla mapowania obiektowo relacyjnego.

Bzdura, szczegolnie jesli mowa o EF Core. To juz NHibernate naklada wiecej wymagan. W EF Core 2.1 w zasadzie ciezko znalezc jakies "wymagania" co do tego jak ma wygladac POCO. No chyba tylko w przypadku wprowadzania many-to-many.

No właśnie o te niepotrzebne Identyfikatory, się rozchodzi.

@Greg1 Ten Code First to nie jest tak jak to przedstawia MS. Oni robią z tego coś na wzór metodologi pracy, co jest mniej więcej żałosne. Ponieważ auto mapowanie ORM'a to nie jest nic nowego. A samo EF pierwotnie miało się skupiać na "DB First", może stąd wziął się problem, o którym wspomniał @somekind, nie wiem...

._. napisał(a):

Odnośnie do tej alternatywy to zabrzmiało jak byś namawiał do nie stosował oddzielnego modelu dla Persistence z Domain Modelem. Czy ja dobrze rozumiem.?

Ja tylko przedstawiam alternatywy. Sam osobiście zawsze skłaniam się do niestosowania DDD na siłę.

@Aventus
DDD niczego nie narzuca, to ludzie sami sobie coś narzucają. DDD to zbiór propozycji projektowych, które nie są nowością, DDD raczej skupia się na ich sensownym zastosowaniu a to nie jest proste. Persistence ignorance to pomysł Fowlera w DDD jest to raczej efekt uboczny stooswania Domain Modelu. W zależności od tego jaką książkę weźmiesz, możesz znaleźć propozycje czerpiące z Port Adapter, SOA, ale i też bez. Ludzie rozpoznają DDD na podstawie tego, że jest tam jakieś repzytorium, domain model i 4 warstwy (W ogóle pomijając coś takiego jak "Mapa Kontekstu" czy "Rdzeń Oddzielony".). Agregat możesz równie dobrze tworzyć bez repository i ustawiać go streamem. Jak masz np. Produkt z ładnymi metodami biznesowymi, który ma kategorie to poco robić wszystko na jedno kopytko. Niech model domeny używa tylko identity filed od kategorii a samą kategorię możesz ustawiać serwisem bazodanowym poza domeną. Nie przepadam za gadaniem typu "DDD alternatywa dla CRUD'a" i na odwrót. Może tylko ja tak mam, ale odbieram to tak, jak by KTOŚ chciał robić wszystko na jedno kopytko. Zamiast trzymać najważniejsze narzędzia za pazuchą i być gotowym do użycia ich w odpowiednim momencie.

Ja nie wiem co Ty tam odbierasz, nie przypisuj mi rzeczy których nigdy nie wypowiedziałem bo to paranoja jakas. Aż mi się nie chce z taką osobą w konstruktywna dyskusje wdawać bo o konstruktywnosci nie ma w takim przypadku mowy.

Aha, i DDD narzuca pewne ograniczenia tak jak wszelkie inne podejścia architektoniczne, standardy i wzorce. Ot choćby w DDD takie agregaty- jak nie masz agregatów, rich entities etc. to nie ma mowy o DDD. Więc ograniczenia, czy raczej pewne narzucone kwestie istnieją. Twierdzenie że tak nie jest to fanatyzm.

To że Cie ludzie plusuja tylko potwierdza jak ograniczeni niektórzy potrafią być i jakie mają problemy z czytaniem ze zrozumieniem- człowiek napisze słowo a reszta doda sobie 10 zdań i ocenia na podstawie tego jak daną wypowiedź "odbiera".

Już rozumiem, z czego wynikają twoje ograniczenia w stosowaniu DDD. Prowadzeniu dyskusji również.

Nigdzie nie napisałem, że to o czym mówię to obraz tego, jak ty myślisz, czy programujesz. Ja po prostu chciałem wtrącić swoje przemyślenia nawiązując do twojej rozmowy z @somekind. Dokleiłem cię na zaczepkę, bo mi nie odpowiedziałeś na pytanie i spodziewałem się rozmowy w przyjaznym tonie. Wiesz może ci się nie podobać to co piszę, czy tam mój awatar, nie wiem, ale obrażanie innych dlatego, że mnie plusują, to już naprawdę jest słabe.