Det som jag i detta inlägg söker är konkreta (och gärna enkla) dagliga exempel på varför det är bättre med domänobjekt än dataset. Jag vill inte ha svar som "det är lättare ur förvaltningssynpunkt att jobba med domänobjekt". Jag vill hellre ha ett svar som "det är lättare ut förvaltningssynpunkt att jobba med domänobjekt som tex när man ska göra X eftersom då inträffar Y vilket inte inträffar om man använder sig av dataset".

PS. Kanske ska jag också säga att jag oftast är för en arkitektur som baseras på domänobjekt än dataset.

Pratade precis om DataSet vs Domänobjekt inför några konsulter, så varför inte fortsätta här ;)

Här är mina argument:

DataSet är en reflektion av en databas (IMDB, In Memory Database) och passar bra när vi kör med "procedurel programming", men inte lika bra när vi använder oss av Object Orienterad Porgrammering, detta delvis pga dess struktur (relationer och databas "kopia") och att vi har inte samma möjligheter till arv och utnyttja desing patterns etc. Det är svårt att bygga ut DataSet med affärs logik. Eftersom DataSet är en "reflektion" av databas schemat så vid minsta förändring i databasen så kan det påverka DataSetet och hela DataSetet måte uppdateras, spec. om vi kör med typade dataset. Kör vi med domänobjekt och en bra ORM, så kan databasen förändras utan att det påverkar modellen.

DataSet innehåller mycket information så som tabeller, rader, kolumner, relationer, metadata etc, vilket gör dom stora och "klumpiga" att transportera. Microsoft sa på PDCn 2003 att de vet om att DataSet är väldigt stora och har försökt få ner storleken på dom. Storleken leder till onödigt mycket data som ska transporteras över nätet. Ett domänobjekt är ett tunt objekt och innehåller bara nödvändig data.

Microsoft har inte vidarutvecklat DataSet sedan .Net 2.0 och som det ser ut nu kommer de inte lägga mer energi på DataSet, utan lägger alla resurser på "ORM", ADO.Net Entity Framework för att fler ocjh fler vill jobba med domänobjekt, vilket Java Communityn gjort i väldigt många år.

Vi måste även tänka på att ett DataSet är mer eller mindre en relationsdatabas och kan inte spegla en objekt orienterad miljö.

DataSet är snabba att komma igång med, dom passar perfekt i små databas driva apps där det inte finns behov av domänobjekt för det vi är intreserade av är enbart ändra direkt i datan som ligger i databasen. Vill vi arbeta med en Databas i minnet, så är DataSet ett väldigt bra alternativ, vi har möjligheter att söka och modifiera data och göra batch updateringar etc. Otypade DataSet är lätta att ändra om underliggande datakälla ändras, typade måste genereras om.

Det går fortare att komma igång och skapa en applikation med DataSet, men krävs mer tid om vi använder oss av domänobjekt, spec om dom ska uppnå POCO. Nu kan vi iofs komma igång lika snabbt med ADO.Net Entity Framework och LINQ to SQL, men "by default" så genererar dom entiteter utifrån databas schemat. Sedan får vi gå in och ändra och modifiera för att få till det. Vilket iofs är bra, för då kan vi komma igång med grunden och sedan modifera och anpassa modellen efter vårt behov. Men det krävs mer tid att få till en bra modell än att använda sig av ett DataSet. När det sedan kommer till underhåll så har det visat sig att en DataSet modell är svårare att underhålla och tar längre tid än vad en domän modell. Martin Folwer har en bra graf på detta i sin bok "Patterns for Enterprise Architecture".

Domänobjekt med en bra ORM behöver inte påverkas av förändringar i databasen. Eftesom ett domänobjekt inte är intreserad i hur det sparas så är det först när modellen ändras som databasen kan bli förändrad. Databas förändringar för att öka prestanda eller normalicera etc, ska inte påverka domänmodellen. Använder vi Otypdate DataSet, så måste utvecklaren veta hur databasens schema ser ut, samma iofs med typade. Men med domänobjekt så arbertar bara utvecklaren mot modellen och har inget behov av att veta om hur databas schemat ser ut.

Finns så mycket mer för och nackdelar men det tar tid att få ner allt.. hoppas det gav några "vs" i alla fall. Men det finns ingen Silver Bullet, båda alternativen är bra i olika sammanhang.

Det är enklare att förvalta eftersom du kan skapa en applikationsmodell om är optimerad för din applikation frikopplad från hur databasen ser ut. Om du gör ändringar i datamodellen så kan du fortsätta använda samma domänmodell medan många förändringar i en databas påverkar direkt hur dina dataset måste se ut vilket gör att du får en större förändring.

Du kan uppnå samma effekt med vyer i en databas men fördelen med domänmodeller är precis som Fredrik säger att de är objektorienterade och du kan bättre modellera hur du vill använda dem.

De är också enklare att underhålla eftersom du kan utöka dem med hjälp av arv, polymorphism, interface, Dependecy Injection mm. Dvs om du tex har en produkt som ser ut på ett visst sätt i de flesta scenarion men i just ett behövs det lite mer information, så kan du använda arv för att bygga på funktionalitet för just det scenariot och du behöver inte skicka med det stora objektet till platser i applikationen där det räcker med den lilla versionen.

Med objektorientering kan enklare skapa valideringar på ex fältnivå som är affärsrelaterade, om du vill ha en regel som säger att du bara får lägga till ordrar upp till 100 000 utan att kunden är godkänd. Så måste du lägga till en abstraktion ovanför dataseten för att lösa det, om du har en domänmodell kan du lägga det i domänmodellen. Det innebär att man inte behöver gissa sig till hurvida man direkt får använda datasettet eller om man måste gå via abstraktionen. Det finns bara /ett/ sätt att jobba med datat.

jag har ett gäng till men nu blev jag trött i fingrarna :P

"Pratade precis om DataSet vs Domänobjekt inför några konsulter, så varför inte fortsätta här ;) "

Var inte du i skåne idag? I skåne finns det väl ingen som använder DataSet istället för Domänobjekt... det trodde jag dog ut när danmark lämnade skåne...

Ärligt talat så har de båda herrarna redan nämt alla viktiga aspekter, och jag har inte så mycket att tillägga mer än.

DataSet skulle jag använda vid små kortlivade applikationer där det inte krävs så mycket affärslogik. Eller där man med applikationen försöker efterlikna en databas till dess funktion. I alla andra fall så är domänobjekten att föredra...

Jag tycker det är viktigt att poängtera att både DataSet och Domänobjekt har sina användningsområden och därför bör båda få finnas, man måste bara lära sig när man skall använda vilket.

- M

Tack för era svar och det ni tar upp håller jag med om. Jag skulle dock velat haft lite mer konkreta exempel från yrkeslivet som man bättre kan använda för att övertyga folk :) Men jag ska försöka sammanfatta det som sagts lite kort

1. Dataset är till för datadriven utveckling och domänobjekt för domändriven utveckling, dvs lite förenklat hur databasen ser ut eller hur verkligheten ser ut. (I Fowlers bok POEAA så bland annat detta upp på sidorna 25-30)

2. Dataset är smarta (stora) objekt och innehåller mycket som man inte behöver.

3. Dataset saknar möjligheten till inkapsling av tex validering m.m. Detta innebär i sin tur att risken för dubblicering av kod ökar samt att det blir mer svår förvaltat.

Jag vet inte om du, Patrik, snuddade lite på detta med enhetstestning. För det är väl lite lurigare att få till det i en datadriven arkitektur? Testerna får nog oftast karaktären av integrationstester än enhetstester. Detta skulle jag nog också sätta upp som en punkt.
4. En datadriven arkitektur är svårare att enhetstesta.

5. Det går oftast att snabbt komma igång med datadriven utveckling.

6. Datadriven utveckling lämpar sig i vissa fall för mindre applikationer. Detta eftersom arkitekturen har en tendens att bli komplex ju större applikationen blir än om man skulle använt domändriven arkitektur.

En sak som jag gärna vill lyfta fram som Fowler tar upp i sin bok är:
7. Det är oftast svårt att lära sig domändriven utveckling men har man väl lärt sig att arbete med det så är det svårt att leva utan det.


Hmm, en sak som jag precis kom att tänka på var att inkapslingsproblemet i punkt 3 skulle kunna gå att lösa genom att antingen skapa ett arv till det typade dataset:t eller genom "partial class" som man tex kan göra i Entity Framework. På detta sätt skulle datasetet närma sig likheten hur ett domänobjekt fungerar samt att det skulle vara möjligt att använda den inbyggda databasmappern. Det som inte är så nice är fortfarande att objektet blir ett stort objekt med massa saker som inte behövs. Jag får också en känsla av att det kan bli svår förvaltat om man inte får till en bra arkitektur kring det hela. Så jag skulle nog inte rekommendera denna väg men den är ändå lite intressant eftersom det blir lite av en mellanväg mellan datadriven och domändriven utveckling. Några tankar i området?

Tyvärr har jag dåligt med rena konkreta exempel, jag har inte byggt något speciellt stort med DataSet sedan 2003.

Kan du intercepta properties med partial eller subclass för DataSet?

Det borde fungera för typade dataset. Jag ska göra ett snabbt test lite senare idag...

Typade DataSet är partial. Interfacet för ett DatSet har många members (för många). Vi vill inte exponera en klass som har ett interface med ett flertal members som vi inte använder oss av, det är bad practice. Vårt interface ska bara ha de members vi vill att en användare ska använda sig av, eller får använda sig av. Med DataSet öppnar vi upp många vägar till att göra fel. Så en defensive och progmatisk utvecklare skulle aldrig returnera ett DataSet via en publik member. När vi skriver kod så är det viktigt att se till så användare inte använder vår kod fel. Detta gör vi genom att begränsa members och bara ha med de members en användare har rätt att använda. Internt är det ok att använda DataSet, men mamn bör veta om att det finns andra alternativ att hämta data, andra som är snabbare, eller ger mer möjligheter mm.

Nu kan jag inte komma år Reflector så jag kan inte se om DataSet har några virtual members, jag tror den är väldigt begränsad. Det innebär att du kan bara extenda DatSet med mer members och göra den ännu större och "klumpigare". Ett fel många utvecklare gör med domänobjekt, är att de designar dom fel, de skapar DTOer och datastrukturer och inte ett objekt.

Här är ett exempel då jag valde DataSet. Jag skulle flytta data från en databas in till en MIS databas. Detta kan lösas på många sätt med tex T-SQL eller DTS paket etc, men eftersom MIS databasen och källdatabasen skulle "syncas" och jag skulle behöva merga båda så valde jag DataSet pga dess merge funktionalitet. Detta också för att kunden har en event tjänst som drar igång .exe apps, så dom ville ha ett program som kunde startas och stoppas mm. Att skapa en domänmodell av detta skulle bara ta längre tid och fyller ingen funktion eftersom det är rawdata som skulle flyttas från en databas till en annan.

Det finns ingen i världen som kan säga att domänobjekt i alla lösningar är bättre än DataSet, så tänk på att det finns ingen Silver Bullet. Det gäller att vara väl insatt i olika sätt att designa applikationer för att kunna avgöra när ska vad användas, få en erfarenhet och använda olika lösningar. De som inte vet om andra alternativ och testar dom kommer ha svårt att se varför domänobjekt är bättre i vissa fall, och DataSet i vissa. De som kommer ha extra svårt är de som inte behärskar objekt orientering utan är vana med procedurell programmering tex VB6 utvecklare.

Testade precis och typade dataset är partial som du säger så de verkar ha tänkt till lite :) Jag håller med i det du säger, Fredrik. Jag tycker dock att tanken vara lite intressant, dvs att skapa en hydbrid mellan data- respektive domän driven arkitektur. Man försöker alltså ta det bästa från de båda världarna. Det är lite av när antites och tes möts och bildar en syntes som är en bättre variant. Jag tror dock inte typade dataset är vägen att ta för att bilda en syntes.

Skulle man lyckats komma fram till en syntes så är vi ett steg närmare silver bullet:en. Det vore riktigt nice om man kunde komma fram till en arkitektur som dels tex går att bygga upp snabbt som i den datadrivna delen men även en arkitektur som tex klarar av att hantera komplexitet bra som i den domändrivna delen. Några tankar? :)

"Det vore riktigt nice om man kunde komma fram till en arkitektur som dels tex går att bygga upp snabbt som i den datadrivna delen men även en arkitektur som tex klarar av att hantera komplexitet bra som i den domändrivna delen. Några tankar? :)"

LINQ to SQL eller ADO.Net Entity Framework, bara en tanke ;)

Det finns två approacher, "Database first" eller "domän first". Tyvärr så är det förmånga som har lärt sig att skapa databasen först och sedan driva designen efter databasens schema. Denna approache stöds i dag av ADO.Net Entity Framework och LINQ to SQL. Med LINQ to SQL så kan du i princip komma igång lika fort som med typade DataSet. Fördelen med LINQ to SQL är att dina genererade klasser från databasen schema är lätta, jämför med DataSet. Med LINQ to SQL har du en databas driven modell och en "domänentitet" (OBS! denna domänentitet är en spegling av databasens schemat och inte från verksamheten, så jag skulle med försiktighet kalla den för en domänentitet)

Med DDD (Domän driven design) så skapas modellen först utifrån verksamheten med hjälp av en domän expert. När modellen är skapad och testad så tar man nästa steg och ser över hur datan ska lagras. Här är det inte intresant med en "hybrid", utan här vill vi mappa våran modell mot datakällan, som ofta är en databas. ADO.Net Entity Framework (EF) kan detta idag, men har bättre stöd för det i nästa version. Utvecklarna ska göra det dom är bra på, och det är att implementera en domänmodell, medans 2DBaer" fokuserar på vad dom är bra på och det är implementation av databasen. Med hjälp av EDM så mappar "DBaer" sitt databas schema mot utvecklarnas domänmodellen. Skulle DBaer behöva förändra på databasens schema vid tex optimering, så ska inte det påverka utvecklarens domänmodell.

Du efterfrågade projekt från yrkeslivet, jag kom i början av min tid på mitt nuvarande jobb i kontakt med ett system för kundhantering på mitt nuvarande jobb, det är byggt kring ett stort typat dataset som har byggts på allt efterhand, jag kom in efter ca 3 år av programmets levnadstid.

Problemen jag har dykt på kanske inte alltid har varit relaterade till att det just är DataSet, wrappar man in DataSet så kan man få det att fungera bra (wrappar in det i en domänmodell ^^) ju bra men i detta systemet så har man valt att lägga all funktionalitet i Formulärsklasserna för att operera på DataSet/Datatabellerna, vilket gör återanvändandet av kod i princip obefintlig, och efter en uppskattning som jag gjort vad skillnaden i mängd kod hade blivit från idag ca 300 000 rader kod till ca 100 000 rader vilket hade ökat underhållbarhet och kvaliten.

Följer man Output så kastas det i princip exceptions från DataSet'et set och get properties hela tiden.

Nu när kundernas databaser växer så har man upptäckt att hmm, man kanske inte ska göra på det enkla sättet och bara fylla DataSet'et med all data som finns i databasen. Så man har gjort ena efter andra fulhacket för att lösa det.

Nu säger jag inte att det måste bli såhär när man använder DataSet/DataTable's men jag tror att dom som väljer denna approach för system som egentligen inte är anpassade till det har lite att lära.

Men min erfarenhet är att DataSet är Quick and dirty way som efter ett tag blir den riktigt långsamma vägen.

Annars tycker jag att DataTable's har en hel del sjyst funktionalitet som sökning med sql liknande queries osv men det går ju att hitta på nätet för objektmodeller med :).



Hoppas du fick någon nytta av min erfarenhet.

-> Fredrik
Jo, Entity framework ja. När jag kom i kontakt med Entity framework för första gången så tänkte jag direkt att detta påminner en hel del om hur typade dataset fungerar fast man har vidareutvecklat konceptet och bytt namn. I början när det kom så kunde man enbart autogenerera entiteterna utifrån databasen (om man inte ville skapa de manuellt förståss). Detta reagerade jag direkt på och det var verkligen inte ett domändrivet tänkt. Jag vet att Microsoft fick en del kritik kring detta och de har utvecklat en autogenerering av databasen från domänen. Jag vet inte hur långt de kommit på detta spår men om jag tolkar dig rätt så ska det finnas en version ute så det är bra. Får ta och testa det...

Om vi filosoferar vidare kring syntesen :) Så försök lägga undan hur tesen och antitesen fungerar idag, dvs om det är databasen som konstrueras först eller om det är domänen. Tänk mer på vad finns det i de båda synsätten som man vill behålla samt vad det är man inte vill behålla.

Fördelen med dataset är som du tog upp innan att det går snabbt och enkelt att komma igång. Nackdelen är att när applikationen växer så blir det svår förvaltat av diverse anledningar. Fördelen med domänendrivet är att den lyckas hantera applikationskomplexitet bättre än dataset samt att applikationskoden på något sätt känns bättre att jobba med. Nackdelen är att det tar längre tid samt att det inte är lika enkelt som dataset (det finns en tröskel som man måste över).

Lite grovt kan man säga att kriterierna för syntesen borde vara alltså:
- Det ska vara enkelt och snabbt att utveckla i
- Det ska lyckas hantera applikationskomplexitet på ett bra sätt
- Det ska vara "behagligt" att se på strukturen

Hinner inte skriva mer... :)

@Krister:

ADO.Net EF som finns ute nu med SP1 av .Net 3.5, har idag generering ifrån database, men om du kan skriva dina egna EDM filer så kan du skapa modellen först. I nästa version så kan du utifrån modellen generera databasen (skulle vara försiktig med detta). Du kan även skapa POCO. Här har du en film från PDC 2008 som tar upp några features som kommer till EF:

http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/TL20.wmv

Du vill inte att dina domänentiterer skapas utifrån databasen, utan istället från hur domänen ser ut, men samtidigt vill du att det skall vara enkelt och snabbt att komma igång.

Frågan är då hur vill du börja. Vill du få hela domänmodellen dirket, så går det inte, antingen så får du skapa den från databasen eller så får det ta tid att skapa domänmodellen. Du kan inte få det snabbt och samtidigt inte från databasen, eftersom utvecklingsvertyget inte har en anning om hur din domänmodell ser ut.

Alternativet är att du börjar med en begränsad del av domänmodellen (AGILE utveckling) och implementerar det, då kommer du igång enkelt och snabbt. Du får dessutom ett bra sett att hanterar kompliexiteten i domänen, och dessutom så är det ett behagligt sätt att se strukturen på. Även om det bara är en mindre del av domänen. Visst du skriver mer kod än om du kör med DataSet och MS klicka-gissa-spring filosofi. Men det är det värt i längden...

DDD utgår ifrån AGILE utveckling och att världen förändras, så det är helt okej att börja med en lite begränsad del av domän när du utvecklar i DDD.

Så då får du allt som du efterfrågar :)

- M

-> Fredrik
Att bara autogenerera databasen från domänmodellen och inte bry sig om att gå igenom resultatet är riskabelt. Men den stora fördelen med autogenerering är att det eliminerar en del "dubbelarbete" genom att man slipper skapa massa datakolumner men även att datatyperna matchar.

Ska kolla på videon...

-> Magnus
Det agila spåret är ett intressant komplement till hur man utvecklar mjukvara men jag har jag tror inte att agile är något som ersätter enkelheten med att arbeta med dataset med ett lika enkelt sätt att arbete domändrivet. Det hjälper att man inte ska tänka för mycket i början eller att bygga massa saker som inte behövs just för tillfället m.m. Men det skulle inte förenklat domändriven utveckling i Fredriks ovannämnda fall med användningen av dataset, dvs att flytta data från en databas till en MIS databas. Så länge det finns liknande skäl att använda dataset som Fredrik nämnde så kommer det vara aktuellt att bygga på en syntes. Jag tycker det borde inte vara omöjligt att eliminera dataset ur vår världsbild :) Men så länge det finns ett skäl i att det går snabbt och enkelt att arbete med dataset så länge kommer dessa leva vidare.

Så jag håller inte med om att det jag efterfrågar finns :)

Krister:

"Att bara autogenerera databasen från domänmodellen och inte bry sig om att gå igenom resultatet är riskabelt. Men den stora fördelen med autogenerering är att det eliminerar en del "dubbelarbete" genom att man slipper skapa massa datakolumner men även att datatyperna matchar. "

Helt rätt, men frågan är om en utvecklare ska ha hand om databasen, ofta blir det och är så, men inte säkert att det är rätt person för jobbet. DBaer som är experter på området är mer lämpade. Att generera från en domänmodell kan leda till ett icke optimalt schema, men skapar en "byggställning" att jobba vidare på.


----

När det gäller Agile och DataSet, så går det utmärkt att använda DataSet i ett agilt projekt, Agile har ingen direkt relation till en viss design eller arkitektur, det är en sätt att arbeta. Men kan hålla med om att Agile är en bra process när vi jobbat domän drivet och jag förstår vad Mangus menar och det är en intresant diskution.

Jag tror vågar nog säga vet att DataSet kommer att försvinna av sig självt i framtiden. Det är bara att se på Microsoft nya tjänster tex Windows Azure operativet för cloud computing och Azure's date storage. ADO.Net teamet och andra team går ut med artiklar, blogginlägg och guidlines kring användandet av Entity Framework, och 80% av .Net communityn gör som Microsoft gör (sorgligt men sant. När jag säger "sorgligt" så betyder inte det att .Net Com. inte ska lyssna på Microsoft, utan att Microsoft kanske inte är det perfekta "svaret" i alla lägen. Det finns många saker som de själva har efterhand bett om ursäkt för, tex DCOM. MEN! De har gjort många bra saker och man ser nu hur Microsoft som företag ställer om sig och börjar erbjuda andra och bra alternativ för det som tidigare va dåligt, och jag gillar vad jag ser, och ser fram mot resultatet).

Håller med att en utvecklare som inte har bra databaskunskaper bör inte pilla med databasen för mycket :) Jag utgick från att alla utvecklare har någorlunda bra databaskunskaper men det är ett felaktigt antagande. Så den tar jag tillbaks...

Angående agil-biten menade jag inte att det inte går att använda dataset och agil. Det jag ville trycka på är att om du valt att jobba agilt så skulle detta inte inneburit att du automatiskt valt bort att jobba med dataset. Det är något mer än ett agilt arbetssätt som krävs för att dataset inte ska vara ett alternativ.

Det ska bli intressant att se vad som händer i framtiden. Titta precis på videon och jag såg demon med databasgenering och det verkar fungera med ett enkelt exempel :) Det som jag inte gillade var att den dumpade all data i databasen. Men där kommer det väl någon form av lösning kan jag tänka mig. Eller hur har man tänkt där?

"DDD utgår ifrån AGILE utveckling och att världen förändras, så det är helt okej att börja med en lite begränsad del av domän när du utvecklar i DDD. "

Intressant iaktagelse. Var i Evans bok står det att DDD kommer från det agila tänket eller att det är på något sätt ens det rekommenderade sättet? Jag vet at Eric är Agil i "real-life" men de flesta av hans teorier funkar lika bra i vattenfall som Agile.

"Intressant iaktagelse. Var i Evans bok står det att DDD kommer från det agila tänket eller att det är på något sätt ens det rekommenderade sättet? Jag vet at Eric är Agil i "real-life" men de flesta av hans teorier funkar lika bra i vattenfall som Agile."

Nja, DDD utgår ifrån att världen och förutsättningarna förändras, Eric uppreppar flera gånger i sin bok att domänen inte är helt känd när man startar sitt projekt och att ju längre tid projektet fortgår destu mer lär man sig om domänen och den kommer att förändras. I en vattenfalls metod, så designar du hela domänen innan du börjar utveckla.

Visst kan man bygga ett projekt i DDD på en vattenfals metod, men med en AGILE metod så kommer resultatet bli bättre :)... Men visst AGILE är bara flera små vattenfallsmetoder, så allt beror ju på hur man definerar vattenfallsmetoden

- M

"Så länge det finns liknande skäl att använda dataset som Fredrik nämnde så kommer det vara aktuellt att bygga på en syntes. Jag tycker det borde inte vara omöjligt att eliminera dataset ur vår världsbild :) Men så länge det finns ett skäl i att det går snabbt och enkelt att arbete med dataset så länge kommer dessa leva vidare."

Jag har inte sagt att datasetet inte har något existensberättigande, precis tvätom (se tidigare poster)

Men det du efterfrågar är en omöjlighet om du inte kan tänka dig att börja med en liten del av ditt projekt (vilket agile förespråkar). Om du gör det så kommer du igång snabbt och får en bra struktur på koden.

Vill du få med hela domän modellen i starten så måste du generera din domänmodell från databasen (vilket inte är en bra lösning) eller så måste du skriva hela domänmodellen innan du fortsätter att utveckla övriga delar av projektet, och det är heller ingen bra lösning. Så det bästa för att komma igång snabbt och få bra struktur på sin kod, är DDD med SGILE utvecklingsmetod.

- M

Angående DDD och Agilge vs vattenfall så innehåller förordet kanske den mest explicita kopplingen till agila metoder.
Där står det nämligen att boken är "oriented toward" agila processer, och där nämns det även att en av två viktiga "prerequisites" är att "Development is iterative", vilket är direkt icke-kompatibelt med vattenfall där man utgår från (den oftast naiva) hypotesen att man kan göra en analys och design som kommer att bli rätt utan behov av iterationer och en refaktoriserad modell.
Men det är klart att visst funkar olika "building blocks" såsom aggregates och repositories även om man tillämpar vattenfall, om man trots allt skulle lyckas få till modellen rätt från början utan behov av iterationer.
Precis som Magnus skriver så är det vissa saker som Eric upprepar ofta i boken, som står i konflikt med vattenfallsmetoden, t.ex. meningar som innehåller uttryck av typen "evolving model", "deeper/new insight of the model", "refactor/update the model".

/ Tomas

-> Magnus
Jag menar inte att du har sagt att du vill bli av med dataset. Det jag vill förespråka är en syntes av de båda världarna så att de blir en. Man får det bästa av de båda världarna. I den nya världen så skulle Fredrik kunna löst sin import på ett smidigt sätt utan att använda dataset. I den nya världen så ska det även gå att hantera applikationskomplexitet m.m. på ett bra sätt.

Jag försöker se framåt, är lite visionär och drömmare :)