DDD: podtřídy a kořenové entity

hlasů
9

Řekněme, že mám typický entity auto

class Car : Entity
{
    public double MaxSpeed { get; set; }
    public Color Color { get; set; }
    /* ... */
}

Tento subjekt, v mém modelu domény, bude kořen subjekt z Aggregate .

Nyní řekněme, že jsem se specializují auta. I vytvořit Ferrari a šťastní majitelé Ferrari chtěl volat jim přezdívkou:

class Ferrari : Car
{
    public string Nickname { get; set; }
}

Řekněme, že mám jiný subjekt, Company entitu. Byl by to kořen subjekt jiného Aggregate . Existuje mnoho lidí, kteří pracují v podniku, reprezentované subjektem osoba . Osoby, které mohou mít vozy. Ale prezident společnosti je obvykle velmi bohatá a tento druh lidí, mají Ferrari:

class President : Person
{
    public Ferrari Ferrari { get; set; }
}

V této situaci, mám subjekt prezident, který je uvnitř do společnosti agregátu , který je drží odkaz na Ferrari, což je specializace kořenového subjektu jiného agregátu.

Je to správné z hlediska DDD? Může / bych měl uvažovat o specializaci sebe kořenových subjektů jako root subjekty stejného agregátu? Myslím, že v doméně jsem popsal, je jednotka Ferrari také kořen entita Car agregátu (protože Ferrari je také Car)?


Nyní řekněme, že musím trvat tento model do databáze . Myslím, že moje otázka není závislá na rámci OR / M budu používat.

Jak mám vytvořit tabulku drží auta ? Měl bych postavit do jedné tabulky Automobily s kolonou „CarType“ (možné významy: „Auto“, „Ferrari“), a s možnou hodnotou Null sloupců přezdívka?

Nebo bych měl sestavit tabulku pro automobily a stůl pro Ferrari, druhý jeden, který má své pKa FK z auta?

Dík!

Položena 26/08/2009 v 23:42
zdroj uživatelem
V jiných jazycích...                            


3 odpovědí

hlasů
4

Byste neměli používat dědičnost modelovat svou doménu, protože se brzy dostanete do problémů najednou modelu začíná být složitější.

President je prostě role osoby a osoby, mohou mít více rolí. Možná, že prezident dostal jen jednu roli, ale to je prostě náhodný výběrem špatný příklad.

Ferrari by neměl být zděděná z auta a to buď. Není to zřejmé na příkladu Ferrari, protože jen to jeden typ vozů, ale vzít v úvahu společnost, mnoho druhů, jako dodávky, sedany, hatchbacky, kamiony a tak dále. Pravděpodobně budete chtít, aby třídy pro každý typ, který se dědí z třídy automobilů. A potom, co ... hodláš dělat pět Toyota tříd, které zdědí od každého druhu? Jako...

Car -> Sedan -> ToyotaSedan
Car -> Truck -> ToyotaTruck
Car -> Hatchback -> ToyotaHatchback

To by bylo směšné.

Disclaimer: Já vím, nic o tom, o autech. Nicméně...

Nepoužívají dědičnost modelovat svou doménu. Vůbec.

Zkuste to bez dědictví, a to se také stalo zřejmé, jak přetrvávají svou doménu.

Odpovězeno 29/08/2009 v 21:21
zdroj uživatelem

hlasů
3

Obecně platí, pokud překročí kořenové agregát hranice povolíte pouze odkaz na mít ID druhého kořenové agregátu. Potom použijte tento identifikátor k vyhledání druhý agregát ve svém archivu.

Takže v případě, že by chtěl prezident mít ID vozu a pokud něco do prezidentova vozu někdy potřeboval byste použili ID Car jít do úložiště dostat auto. Prezident by neměl odkaz na samotný automobil.

Nyní o tom Ferrari. Je to docela těžké prosadit, že ve standardní terminologie DDD. Za normálních okolností byste dát nějaké potvrzení o přidělení auto prezidenta. Nebo je snad CarBuyingService jen předsedů, která zajišťuje, že si to pravé. Za normálních okolností v DDD specializací nejsou samy o sobě kořenové agregáty.

Odpovězeno 29/08/2009 v 21:23
zdroj uživatelem

hlasů
2

Myslím, že se začnou ztrácet hodně pružnosti systému vytvořením konkrétních typů těchto subjektů. Typ vztahu, který jste z čehož vyplývá, je něco, co obvykle ručně pomocí „Typ“ subjektu. Například máte auto. Ferrari je typ vozu. Tyto dva subjekty, které nesou z toho jsou auta a CarType.

Způsob, jakým se mluví o tom to, museli byste přidat nové entity pokaždé, když je zaveden nový typ. Pokud vše, co se snaží zachytit je „přezdívka“ auta, myslel bych si, že je to jen další část dat, a ne jiný subjekt. Pokud mají různé údaje (tj různé názvy vlastností) a / nebo chování rozdíly mezi osobami auto k různým typům, nechcete získat hodně s tímto přístupem. Raději bych úložiště metody, jako je FindCarByType () a vypořádat se s jedním typem entity, ke snížení rizika.

Jsem v žádném případě odborník DDD, a já potýká s některými pojmy (nebo spíš zápasí s mnoha interpretacím některých pojmů). Jsem zjistil, že tam není 100% čisté realizace, a že existují nuancí každé plnění, které jsem viděl.

editovat Vyplývá

Vidím, že jsem špatně přečetl část toho, co jste napsal. Vidím, že přezdívka není pro všechna vozidla, ale jen za Ferrari: Car. Myslím, že odpověď je opravdu „to záleží“. Kolik domén zaměření máte na celý zbytek svého modelu? Poté přezdívka by mohla být převládající mezi subjekty Ferrari, ale je to exkluzivní? Nejde jen o skutečných dat, ale požadavky. V podstatě jde o to, kolik zaměření vašeho očekávají v těchto subjektů.

Odpovězeno 29/08/2009 v 20:52
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more