Har lite svårt att få till det med contextbounds med DDD. Har förstått själva principen med contextBounds att ex: En användare ser olika ut för en Order och en Faktura. Och det då bör skapas 2 olika User objekt ett för varje contextBoundery, och sedan mappa information mellan dessa när de skickas över "context-gränserna"

Nu till själva iden med att spara ner denna användare till databasen, där dessa 2 olika användare kan ha olika egenskaper på sig som måste sparas ner till databasen, jag vill ju ha all denna information samlad i en User tabell, så jag inte har en UserOrder och en UserFaktura tabell.

Det som jag tänkte mig är att man helt enkelt låter respektive boundery sköta sin "del" av sparandet till databasen och låter de andra kolumnerna som denna boundery inte använder vara orörda. Det som jag ser som nackdel är att mitt UserRepository antingen kommer att ta emot 2 olika User objekt, eller så kommer jag få ha olika UserRepository, ett för varje boundery?

Alternativ att man har en "master" User som innehåller alla egenskaper som man måste mappa till när man vill spara/hämta från databasen, men det känns inte helt rätt, denna "master" finns så fall i min domän bara för att lösa något tekniskt?!?!?!?!

Hur har ni löst det?

- M

Vad menar du med att användaren ser olika ut för en faktura och en order? Vad är det som skiljer dem åt?

Det var bara ett exempel. I mitt fall så har jag en entity som heter Player. Denna Player har olika properties på sig beroende på i vilket contectx jag är i min domän.

Exempel vis så vill jag ju kunna ha en email-adress på min Player, så jag kan maila till honom, men när jag skall skapa olika lag så är information så som email-adress helt ointressant, det som är intressant då är typ: Namn och SkillLevel. Medans SkillLevel är helt ointressant om jag skall skicka ut meddelande via email till spelaren. Då är det ju Namn och EMail som är intressant.

- M

Jag skulle bygga upp det med en tabell som heter Person som endast innehåller uppgifter om personen, t.ex. Namn och födelsedatum. Sedan har du en annan tabell som heter contactinfo som relaterar till personen (eller tvärt om) och så ännu en som heter t.ex playerinfo.

I koden accessar du den med
Person.ContactInfo.Email
Person.PlayerInfo.SkillLevel

För mig känns det som det naturliga sättet att gå till väga och jag ser inget fel i det. Det är säkert möjligt att göra något i stil med
Person.Email
Person.SkillLevel
utan att behöva lägga allt i samma tabell också. Men jag föredrar det andra sättet.

Men själva idén med DDD är ju att man inte ska tänka utifrån databasen utan utifrån klassstrukturen.

Så bestäm först hur du vill att det ska fungera och tänk sedan på databasen.

>>Nu till själva iden med att spara ner denna användare till databasen, där dessa 2 olika användare kan ha olika egenskaper på sig som måste sparas ner till databasen, jag vill ju ha all denna information samlad i en User tabell, så jag inte har en UserOrder och en UserFaktura tabell.

Det är där du gör fel IMO.

Det bör bara vara ett av dina contexts som "äger" användare.
I alla andra contexts bör användare vara en readonly projektion från ägarsystemet.

Säg att du har ett subsystem för användare och behörigheter.
ett annat för att hantera orders och ett för att hantera lagersaldon.

Då bör det bara vara användar subsystemet som får skapa användare, de andra systemen kan ha tillgång till användare i lite olika utformning, men aldrig skriva.

Om ett annat subsystem vill skapa användare så bör de snarare skapa en förfrågan och skicka denna till subsystemet som hanterar användarna.
(Det kan ju vara så att användarsystemet ger avslag på förfrågan också)

Det är iaf mitt sätt att se på det hela.


>> Alternativ att man har en "master" User som innehåller alla egenskaper som man måste mappa till
>> när man vill spara/hämta från databasen, men det känns inte helt rätt, denna "master" finns så fall i
> >min domän bara för att lösa något tekniskt?!?!?!?!

Njae, den finns där för att hantera domänen av användare.
Förutsatt att det inte är _helt_ olika relger o egenskaper för dina olika subsystem.
Då skulle jag nog påstå att det handlar om olika typer av användare, och därmed inte borde hanteras/lagras ihop.

//Roger

"Då bör det bara vara användar subsystemet som får skapa användare, de andra systemen kan ha tillgång till användare i lite olika utformning, men aldrig skriva.

Om ett annat subsystem vill skapa användare så bör de snarare skapa en förfrågan och skicka denna till subsystemet som hanterar användarna.
(Det kan ju vara så att användarsystemet ger avslag på förfrågan också) "

Men problemet här blir då att jag får en "master" person som innehåller all information som kan finnas i alla context. Så om vi nu tar 2 alternativ. Jag har en shoppingsite, och på denna shopping site så kan du logga in som användare och beroende på vilken användare du är så får du se olika sidor! Typ en IsInRole()-funktion. Efter det så har jag ju möjligheten att lägga orders och för det så måste jag ha en Address.

För själva inloggningen så behövs inte Address- informationen och för att lägga order så behövs inte IsInRole()-funktionen. Vilken av dessa 2 context tycker du att jag skall "skita" ner med information som inte behövs för att jag skall få en context som "äger" Person entiteten?

Nej ju mer som jag tänker på det så blir det mer rätt med att separera dessa som 2 olika entiteter, där man egentligen bara behöver ID för att hämta rätt information från sitt repository i respektive context. Att alla information råkar finnas lagrade i samma tabell i databasen under spelar ju ingen som helst roll för mina entiteter. Så när jag mappar mellan 2 olika person entiteter SecurityPerson och OrderPerson så blir det inte så mycket mappat, utan man skickar med ID från den ena contexten till den andra som får i uppgift att hämta den information den behöver för att klara av sin context! Blir ju lite mer databastrafik, men betydligt bättre separerat än att ha en "huvudentitet" som sedan alla andra entiteter skall hämta/skriva information till....

- M

Spontan tanke:
Du har en Person. Person innehåller allt.
När ett subsystem (säg "visa-sidor-delen") behöver något får du ut ett nytt objekt (en projektion) som bygger på Person, SecurityPerson, i princip något i stil med:

SecurityPerson p = PersonHandler.GetPerson(ID).ToSecurityPerson()

eller

SecurityPerson p = PersonHandler.GetSecurityPerson(ID)

Där:
PersonHandler.GetSecurityPerson(ID) {
Person p = GetPerson(ID)
return p.ToSecurityPerson
}


Jag gissar att det här är ungefär så som Roger menade också?
Du har en master-Person, men samtidigt så existerar den bara i "PersonHandler".

Ett annat alternativ skulle helt enkelt kunna vara att låta SecurityPerson och OrderPerson vara interface. Det finns bara en klass "Person", men beroende på var i systemet man är arbetar man mot olika delar av den.

Eller säger jag självklarheter?

<i>"Ett annat alternativ skulle helt enkelt kunna vara att låta SecurityPerson och OrderPerson vara interface. Det finns bara en klass "Person", men beroende på var i systemet man är arbetar man mot olika delar av den."</i>


<i>"Alternativ att man har en "master" User som innehåller alla egenskaper som man måste mappa till när man vill spara/hämta från databasen, men det känns inte helt rätt, denna "master" finns så fall i min domän bara för att lösa något tekniskt?!?!?!?!</i>


Problemet som jag ser det med denna "master" klass är att den finns till baraför att jag skall spra ner informationen någonstans och "passar" inte in i domänen egentligen.

- M

Ja, ok, men då är det ju en fråga om hur viktiga "Users" är. Antingen är users bara en liten detalj, och då finns det, som Roger säger, ingen direkt anledning att hantera dem som samma sak alls.

Eller så är "användare" en viktig del, som logiskt hänger samman genom flera delsystem, och då är det ju inte för att lösa en teknisk detalj, utan då representerar du en viktig entitet som en klass.

Annars skulle du kunna använda samma argument för alla entiteter i hela systemet.

"Eller så är "användare" en viktig del, som logiskt hänger samman genom flera delsystem, och då är det ju inte för att lösa en teknisk detalj, utan då representerar du en viktig entitet som en klass.

Annars skulle du kunna använda samma argument för alla entiteter i hela systemet."

Det är klart att jag kan resonera så om alla entiteter i varje context! Men det är ju inte alla entiteter som delas över flera context. Och de som gör de, bör ju vara unika för sitt context annars så bär de runt på en massa onödig information...

Frågan blir då istället "hur stora" skall mina context vara, skall mitt system bestå av 1,2 eller 10 olika context? Det blir ju lite beroende på hur man definerar sina gränser för vad som kan ingår i samma context. En shoplösning kan ju delas upp i flera olika context eller så blir det bara ett context, allt beroende på hur pragmatiskt man är när man delar upp contexten.

- M