Jag har några klasser som jag fyller med grupperaddata från databasen. Det kan tex vara bokningsstatistik. Men hur ska man se på dessa klasser utifrån ett DDD-perspektiv? För de kan väl inte klassas som entiteter. De känns mer som value objekt men ändå inte.

"grupperaddata"?
Det är ovanligt med felaktiga ihopskrivningar i svenskan... =)


<disclaimer>knappast ddd-guru, men med en basic förståelse av ddd och lite sunt förnuft så:</disclaimer>
Det här är ett typexempel på när jag tycker att oo går till överdrift. Visst, man kan väl antingen tänka sig någon form av "statitistikobjekt", som ju då definitivt (?) är ett value object, och immutable.
Eller så kan man se det som en entitet eftersom statistik beräknas för ett visst urval av objekt och detta urval är en identitet, och vidare kan man väl se det som en egenskap hos själva samlingen av objekt.

Det sistnämnda är ju kanske "snyggast", att man har en CustomerCollection.StdDevOfAge, och sen arbetar med slices om man vill det, och tar fram samma statistik för dem.


Men jag tycker ändå att det är ju för fan inget "objekt" - det är en radda tal som är väldigt logiska att ha tillsammans. På något sätt känns det fel att pressa in det i en metodik där det inte riktigt passar in.

Jag håller med om att det med att bygga upp en skräddarsydd-kollektionsklass är rätt nice, Det gillar jag lite men samtidigt ser jag en stor risk att det blir för tung kollektion att arbete med. Har man 1 000 000 bokningar och ska börja beräkna fram medeltal så blir det ett riktig tung kollektion. Men jag gillar tanken...

Om du inte vill pressa in det i ett DDD-sammanhang. Var vill du pressa in en sådan klass? Utanför domän-projektet eller inne i någon mapp i projektet? Vilken mapp i så fall?

<b>Det gillar jag lite men samtidigt ser jag en stor risk att det blir för tung kollektion att arbete med.</b>
Du behöver ju inte de facto _lagra_ alla objekt. Om vi tar några genvägar och säger att du har en konstruktor:

CustomerCollection(string city);

Om man bara hämtar ut statistik, säg:

cc.GetAverageAge()

så gör den (direkt eller indirekt) ett sql-anrop i stil med

SELECT MEAN(Age) FROM Customers WHERE City = "..."

Men om man vill iterera igenom den eller hämta ut enskilda objekt, så hämtas själva objekten. Allihop, en och en, eller i chunks.

Detta är ju förstås väldigt likt vad som händer i linq to sql, och är nog väldigt enkelt att mappa lite tätare. Det är synd att .NET-språkens generics ligger en del efter, annars hade man kunnat göra riktigt häftiga grejer.

Spontant skulle jag säga att det är en service, i stil med en rapporttjänst... Men det beror ju lite på hur man ska använda den, ibland kan ju tex. affärslogik vara beroende av statistik.

En service är bra att ha men jag vet inte om en service ensam löser det hela. Vad returnerar tex en sådan service till GUI:t? Ett dataset eller ett statistikobjekt? Eller menar du att servicen i sig innehåller properties med den grupperade datan? Det sistnämnde tror jag inte är riktigt bra...

Servicen borde väl returnera någon form av dto, lite beroende av hur datan ska användas. Dataset är väl utmärkt om man tex. ska visa resultatet i en rapport, annars hade jag nog valt något struct-liknande.

Och det är ju det jag menar med att det blir lite awkward att försöka knö in det i en struktur.

Alla alternativen är ju rätt. Ett enskilt objekt med alla värdena blandat som är immutable och bara ett värde funkar ju.

Det var nog feltänkt av mig när jag sa entitet. Läste precis en text där någon skrev att tumregeln var att "om ett objekt har en identitet ska det vara entitet". Det är ju frågan om ett objekt med en viss identitet, men med bara readonly-värden.

Slutligen är det ju mycket logiskt att koppla det till den faktiska samlingen objekt. Då får man både med själva objekten och urvalet. Däremot kanske det inte funkar något vidare i sammanhanget - ibland är statistiken något helt separat från det den bygger på, ibland syns de alltid tillsammans.