Hej

Är det någon som vet var man kan läsa om hur man ska bygga en bra design? (Web, böcker, dokument, artiklar..)

Jag utvecklar ett GUI i C# i Visual Studio 2005.

Gui:et jag gör vidareutvecklas ständigt, vilket innebär att det från början inte funnits en färdig spec. Risken då är ju att koden växer och kanske inte är så generell till slut.

Dessutom vill olika kunder ha olika funktioner och varianter av programmet.

Jag vill absolut inte ha ett projekt per kund och detta har jag än så länge lyckats undvika. Men jag är ändå inte helt nöjd med min design.

Tack!
/Sofia

Det finns två författare som jag tycker är viktiga i sammanhanget. Det är Martin Fowler och Robert C Martin. I alla fall vad gäller grundläggande OO analys, design och implementation. De två böckerna som jag rekommenderar alla att ha läst är dessa:

http://www.amazon.com/Principles-Patterns-Practices-Robert-Martin/dp/0131857258/ref=pd_bbs_sr_2/104-1042542-1993514?ie=UTF8&s=books&qid=1181674879&sr=8-2

http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/ref=pd_bbs_sr_1/104-1042542-1993514?ie=UTF8&s=books&qid=1181674847&sr=8-1

Sen har min koillega Fredrik Normen skrivit ett par bra blogginlägg om specifikt hur du bygger webbgränssnitt som måste klara förändringar:

http://fredrik.nsquared2.com/ViewPost.aspx?PostID=416
http://fredrik.nsquared2.com/ViewPost.aspx?PostID=417
http://fredrik.nsquared2.com/ViewPost.aspx?PostID=419

Jag har läst något om att Service orienterat är det man ska använda sig av idag? och att Object orienterat hör till 90 talet? hur är det med detta igentligen?

om man lyckas bygga en sk soa lösning utan en objekt orienterad design i botten är med stor sannolikhet ute och cyklar på djupt vatten :)

SOA och OO är två olika abstraktionsnivåer.

Du kan visserligen ha SOA ideer inne i din implemnation av din webbapplikation men du kommer behöva OO för implementationen.

Aha noterade inte att det handlade om SOA(som jag inte är så värst insatt i).

Jimmy, får man fråga var du läst det så ovanligt klarsynta att OO-design hör till 90-talet och att SO är framtiden?

Patrik, jag skulle vilja citera Don Box från ett dokument du säkert läst:
"Service-orientation differs from object-orientation primarily in how it defines the term "application." Object-oriented development focuses on applications that are built from interdependent class libraries. Service-oriented development focuses on systems that are built from a set of autonomous services."
Det är absolut inte bara olika abstraktionsnivåer vi pratar när vi jämför SO och OO, utan två diametralt olika paradigmer för mjukvarudesign. Visst kan en service implementeras mha OO-språk, men det är inte intressant i sammanhanget.

Här har du en bra sammanställning över GOF-mönstrena:
<url>http://www.dofactory.com/Patterns/Patterns.aspx</url>

Tack så mycket Patrik. Jätteintressanta länkar.

Tack också till Pontus för din länk som även den verkar vara väldigt intressant.

Kul med diskution kring SOA och OO. Jag vet inget om SOA men blir helt klart nyfiken nu.

Jonas Ekström, kanske var det hårt draget men jag har läst detta i diverse Power points från Microsoft, blandannat kan man se det på Bild 5 här : http://download.microsoft.com/download/3/2/e/32e8c73f-b6c2-4b20-b794-ba1ee98398de/Dev003_@GijsdeJongPart_I.ppt

Det står lite mer om det här : http://www.windowsdevcenter.com/pub/a/windows/2007/04/10/the-logic-of-service-orientation-plus-14-so-tenets-and-practical-principles.html

Att man kombinerar de olika är nog inte helt ovanligt.

Sen undrar jag, om man söker på Service-Orientation så hittar man en hel del om SOA, jag antar att SOA står för Service-Orientation Architect ?

Som sagt jag är inte helt hemma på detta så det skule vara intressant med en lite förklaring.

Med tanke på att frågan handlade om hur du bygger asp.net applikationer så är frågan väldigt relevant. Du skapar inte ditt gränssnitt med SOA.

Don Box är, som så många andra MS Soa människor, helt fel på det. Han jämför MDA med SOA, inte OO. Du kan inte med OO definera "applikation" eller "service" eller ens "arkitektur" OO är en teknik du använder i din plattform för att implementera vad det nu är du vill bygga.

Beat sa många bra saker på Developer Summit, men en av de bättre var ngt i stil med "det de flesta SOA advokater glömmer är att i änden av alla dessa tjänster så kommer det att finnas ett gränssnitt som en användare kommer nyttja".

Det är rätt i att gränssnittet på en tjänst skiljer sig från en OO modell baserad på Customer / Order och där modellen är den enda OO du tänker på. Men om du tex tittar på DDD så ser definitionen helt annorlunda ut med många fler spelare. Service är tex en av dem.

Skillnaden på en service i DDD och en i SOA är att kontrakten kommunicerar med objektshiearkier isf så flata meddelanden som möjligt. Det har helt enkelt med att göra att DDD servicar inte är en "point of distribution". När DDD pratar distribution så kommer ofta SOA in som en möjlig arkitektur för det, många DDD lösningar som byggs som tjänster har två modeller, den som sköter affärsproblemet som tjänsten skall klara av (Domän Modellen) och den som används för kommunikation utanför tjänsten (meddelande modellen).

Så jo, SOA och OO är olika abstraktionsnivåer. Vad Don menar är att meddelandena inte är OO. Han har för övrigt också sagt det inte så nyktra "the only abstraction level you need is message".

Eftersom du är pappa ledig så kanske du kan planera in en lunch eller öl så tar jag med mig datorn så skall jag visa ett projekt som använder SOA som arkitektur men där tjänsterna implementeras med OO/DDD. Dvs olika verktyg för olika abstraktionsnivåer.

Patrik, för det första så ser jag inte att Sofia har skrivit att hon avsåg ASP.NET och för det andra så tror jag din definition av OO är felaktig. Du tar lite väl lätt på OO ifall du inte ser att OO influerar en objektmodell. Om nu OO enbart är en implementationsdetalj som du säger så var går då gränsen för vad som är en detalj och vad som är en del av en modell? Även om du implementerar en service med objektorienterade språk så bygger du den baserat på en objektmodell. Samma sak med ett GUI som självfallet mappar väl mot en objektmodell m a p screens, canvas, panels, controls, button, lists, etc.

Jag likställer inte OO-modellen med OO-språken men menar att OO är ett subset av MDA. OO-modellen genomsyrar hela applikationer och system idag och inte bara implementationen av enstaka enheter (som services). Visst är det OO-modellen jag menar är skadlig och bör förpassas till 90-talet (eller 80-talet enligt Jimmys slides). OO-språk används för implementation av det mesta, men inte allt. Ju mindre desto bättre eftersom den objektorienterade modellen influeras och påhejas av bl a Java och C#.

DDD utger sig för att vara en ganska generisk modelluppbyggd metodik, men visar sig praktiseras med ett gammalt objektorienterat synsätt. Tyvärr måste jag även säga att guden bakom DDD (om du nu tolkar Evans rätt) har missförstått SOA om SO beskrivs som klistret mellan objekt i en domänmodell. Kanske lurades han av namnet SOAP, men saken är ju den att DDD i så fall kommer att återupprepa samma misstag som CORBA skapade i sin iver att skapa lösare kopplingar mellan komponenter.

Öl är taget!

Jimmy, jag ägnar viss tid åt att tolka olika synsätt på SOA (Service-oriented Architecture), se här:

http://choreographictechniques.blogspot.com/2007/06/soa-ur-olika-perspektiv.html

Tänkte inte blanda mig i denna diskution men den böjar bli mer och mer intresant.

Vi börjar med DDD:

"Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. " Eric Evans

Vi kan mycket väl skapa Services med DDD, i alla fall engligt mig, om jag har rätt eller fel är en annan fråga. Men när jag bygger mina tjänster så använder jag DDD för den underliggande logiken och modellen som Servicen ska använda för att fungera. En service måste ju utföra något för att vara en tjänst, och den kod och den modell jag använder för att skapa det Servicen ska utföra, är just DDD.

Många skriver SOA vs DDD etc, men jag förstår inte varför.. för för mig är SOA != DDD, men SOA och DDD kan mycket väl fungera ihop, om man fukucerar på SOA när det gäller den övergripande arkitekturen, och DDD på implementationen av en tjänst.

OO för mig är det stöd som finns i ett språk som södjer skrivandet av min applikation, där arv, polymorphism etc kan användas för att återanvända kod etc. Mycket till för att lösa problem.

Sedan har vi OOP:

"Object-oriented programming (OOP) is a programming paradigm that uses "objects" to design applications and computer programs. It uses several techniques from previously established paradigms, including inheritance, modularity, polymorphism, and encapsulation."

För mig funkar även OOP när vi ser på koden bakom en tjänst.

Så för mig med min lilla kunskap, så är SOA på en högre nivå, den övergripande akritekturen över hur man ska bygga apps idag som behöver flera sätt att utbyta data och tjänster med varandra etc (För mig ofta i större lösningar, där olika system måste kunna kommuniceras med varandra, tex banker, logistikföreteg etc, funkar även i mindre applikationer, men där är jag väldigt noga så jag inte överdriver användandet av tjänster om det inte behövs). Sedan när man kommer till själva implementationen av en tjänst, jag då kommer DDD in i leken.. så ser jag det i alla fall så har jag använt det.. Sedan kan ju det vara helt fel.. men det funkar och så länge det funkar så håller det för mig :)

/Fredrik Normén
ASP.Net MVP - Cornerstone
blog: http://fredrik.nsquared2.com

Du har redan blandat dig in i diskussionen nu Fredrik ;)

Du pratar om övergripande arkitektur och skiljer den från implementationen. Du säger att SOA är den övergripande arkitekturen och DDD har med implementationen att göra. Som exempel på övergripande arkitektur nämner du företag som utbyter information men reserverar dig för att använda tjänstebegreppet på applikationsnivån och nedåt.

Jag tror det är en ganska vanlig syn på SOA och tjänster och inte alls en felaktig. Men gräver man lite och gör några arkeologiska undersökningar på SOA så finner man att SOA har en fiende nummer 1 och det är applikationsbegreppet. Applikationen som kapslar in funktion och information i en silo byggd i betong. SOA handlar om att bryta upp applikationerna i små delar (tjänster) som kan återanvändas, styras, bytas ut osv.

SOA har alltså med Enterprise Architecture att göra, d v s hela IT-landskap (och applikations-landskap). SOA är en motreaktion till statiska IT-landskap som pga applikationerna inte kan förändra sig med tiden och med verksamheten. Verksamheten som den begränsar till att utveckla sig i den takt som krävs för att hänga med i föränderlig värld av uppköp, sammanslagningar, out-sourcing m m.

SOA handlar alltså om att applikationsgränserna suddas ut och ersätts av ett nätverk av sammankopplade tjänster. Bygger man ett nytt system så bygger man det alltså baserat på ett antal tjänster som vid implementationen i ett företag kan bytas ut mot interna specifika tjänster för just det företaget. Möjligheten att kunna förändra hur tjänster kopplas samman ligger i den bus som man kallar ESB (Enterprise Service Bus). ESBn ansvarar för att skapa det virtuella lager av tjänster som rent fysiskt kan vara allt annat än XML Web Service. SOA är både stort och smått, det är en utopi som man inte ska lägga för stor vikt vid eftersom det säkert är praktiskt omöjligt att realisera ändå. ;)

Angående DDD måste jag tyvärr säga att det för mej känns aningen andligt och till och med religiöst men framför allt ger det ett förvirrat intryck. Så fort man uttalar sig om det så får man höra att man inte är påläst och så refereras det till ett antal schamaner som fungerar som präster som ska förmedla mellan människa och skaparen. Liksom religion så är det även mångtydigt, men bottnar ofta i exempel som är lika självklara som att det är bättre att vara rik och frisk än fattig och sjuk. Jag har lyssnat på schamanerna, läst böckerna, bloggarna, etc och måste säga att jag har svårt att hitta styrka i den här religionen.

Ta t ex valfri av nedan och berätta för mej om det är pedagogiskt övertygande. Mitt huvud snurrade runt som en karusell efter lyssnat till dessa. Notera att det inte har att göra med varken Jimmy el. Eric eftersom jag vet att de i andra sammanhang kan förklara saker och ting utan problem.

- http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design
- http://www.dotnetrocks.com/default.aspx?showID=194
- http://www.dotnetrocks.com/default.aspx?showNum=236

Hej Jonas

Om man byter ut DDD mot SOA i din post så blir det:

"Angående SOA måste jag tyvärr säga att det för mej känns aningen andligt och till och med religiöst. Så fort man uttalar sig om det så får man höra att man inte är påläst och så refereras det till ett antal schamaner som fungerar som präster som ska förmedla mellan människa och skaparen. Liksom religion så är det även mångtydigt, men bottnar ofta i exempel som är lika självklara som att det är bättre att vara rik och frisk än fattig och sjuk. Jag har lyssnat på schamanerna, läst böckerna, bloggarna, etc och måste säga att jag har svårt att hitta styrka i den här religionen." :P

Jag tror att hur vi än vrider och vänder på det så kommer vi alla hamna i en liknande diskution mellan kirstna och icke kristna. Där icke kristna vill övertyga kristna om att de tror på fel saker, och de som är kristna försöker bevisa att de vet och har rätt etc.. Jag har inte försökt få folk att inte använda SOA, jag säger inte att SOA är fel. Men jag säger som jag brukar säga till folk:

Varje projekt är unikt, och man väljer modeller, arkitekturer och patterns etc efter projektet, för det finns ingen silver bullet.

Här är en intresant post om varför SOA och DDD inte går att jämföras, och hur jag ser på dom båda:

http://weblogs.asp.net/ahoffman/archive/2006/09/09/DDD-and-SOA-Are-Unrelated.aspx

/Fredrik Normén
ASP.Net MVP - Cornerstone
blog: http://fredrik.nsquared2.com

Jag tog mej tid och förklarade min syn på SOA så du får gärna beskriva hur du ser på DDD på ett liknande sätt. Kanske ger det en förklaring till vad jag anser vara en void *.

Ok, ska försöka ;)

DDD används vid implementering av tjänsten. OBS! Hur en tjänst är implementerd inom SOA är oviktigt, det är inte alls intresant om det är VB-Script, Ruby, Perl, C# eller T-SQL etc.. Det är viktigt att tänka på att DDD kan användas vid implementation av en tjänst. Det är därför SOA inte kan jämföras med DDD (enligt mig). Vågar nog säga att DDD kan jämföras lite med Windows DNA (när vi tittar på implementationen av ett system), där man jobbade med skiktade lösningar med BLL och DAL etc.. Så DDD vs DNA är mer relevant enligt mig.

/Fredrik Normén
ASP.Net MVP - Cornerstone
blog: http://fredrik.nsquared2.com

DDD kan alltså användas vid implementation av en tjänst, men vad är det man använder sig av egentligen rent konkret? Vad är det för tankesätt som du refererar till i föregående inlägg.

Du liknar DDD vid Win DNA som är en klassisk applikations-arkitektur. Men enligt mej så är SOA en arkitektur som river upp den klassiska, skiktade arkitekturen för att den är så statisk (se varför i en diskussion jag hade med Patrik Löwendahl här på forumet http://www.pellesoft.se/communicate/forum/view.aspx?msgid=247510&forumid=128&sum=0). Så om SOA river upp det DDD kan jämföras med, så hur skulle då DDD kunna samexistera med SOA?

När du tänker på DDD när du sitter i ett projekt, vad är det då du tänker på? Jag vill förstå!

Jonas:

(Nu är det fel att göra en 100% DDD vs Win DNA, eftersom DDD inte är en arkitektur, men DNA har oxå ett tanke sätt för hur tex en applikaton, tjänst etc ska byggas eller skulle då DNA va aktuell).

Kan vända på frågan, hur implementerar du en tjänst.. Svaret blir nog olika sätt.. men låt oss säga att den kräver viss affärslogik och sin egna datakälla etc och du väljer tex .Net eller kanske Java ;). Hur gör du då? Har du en tjänst som representerar DNA's DAL och en som representerar DNA's BLL som skickar SOAP meddelanden mellan varandra över olika app-domains etc!?

När du pratar om SOA så är det för mig så abstrakt, du nämner inte implementationen av en tjänst, hur ser den ut, hur skapar du den, vilka metoder, vad använder du etc.. tja, nu är det iofs oviktigt hur den implementeras, men jag säger att DDD kan användas vid implementation av en tjänst inget annat. Det är precis vad mina inlägg handlar om.. implementation inte SOA vs DDD för det går inte.

Jag tycker att vi tar denna diskution utanför detta forum, för vi kommer ingen vart och jag tror inte andra är så intreserade av våran diskution... känns mer som vi pratar med varandra fast via detta forum just nu, bara en tanke ;)

Om du inte misstycker så tror jag det här forumet är lika bra som något att diskutera SOA vs DDD.

Jag vill gärna förstå DDD, men nu skickar du tillbaka frågan till mej. Du säger att DDD har med implementation att göra, men vad har inte det? Du nämner tjänster som ska implementeras mha DDD, men vad är det du avser? Är det bara tjänster man implementerar med DDD?

Men jag svarar gärna på hur jag ser på SOA. Återigen så talar jag uytifrån mitt eget perspektiv på vad en SOA är och jag anser inte att en SOA beskriver hur man realiserar tjänster (dvs SoC, taxonomi, språk, etc). En SOA är som jag sa en motreaktion på statiska applikationslandskap. Applikationen ska inte utgöra ett boundary för information och funktion. Funktion och information ska tjänstefieras och kunna manageras i en arkitektur som man kallar SOA för att bygga löst kopplade nätverk av tjänster.

Man kan iofs säga att en ESB är en SOA-implementation, men SOA säger inte vilka tjänster och hur dessa ska implementeras. Se här http://moveflow.blogspot.com/2007/02/how-what-when-and-why-soa.html.

För att frångå lite från trenden i forumet tänkte jag försöka svara på din fråga istället för att skapa en egen debatt. Även om du inte ska bygga ett eget framework så tycker jag att du ska skumma igenom den här boken: http://www.adlibris.se/product.aspx?isbn=0321246756
Den ger många bra tips som kan ge dig idéer om din design. Jag är absolut ingen arkitekt, men jag tror att det är viktigare att bilda sin egen uppfattning om en bra design innan man börjar tillämpa och förespråka de tekniker som tidigare har nämnts här. Med det menar jag inte att man ska fulkoda och uppfinna hjulet på nytt, men jag antar att fokus ligger på leverans snarare än att fundera på vilken jordens bästa systemlösning är i detta fall. Du får väl sedan migrera din applikation till en designmodell som du tycker passar.

Vad det gäller det grafiska användargränssnittet tycker jag personligen det är exemplariskt att särskilja det så mycket som möjligt med procedurell kod a la Windows Presentation Foundation. Det kan tyckas vara en självklarhet, men det är det ofta inte.

Du beskriver inte vad det är för applikation du bygger, men varför kan du inte ha ett projekt per kund? Om de nu skiljer sig åt kan det väl vara idé att ha det och sedan skapa generella klassbibliotek, tjänster och andra gemensamma resurser som projekten delar på.

Hans

Tack för länken! Tips och ideer är just vad jag behöver.

> varför kan du inte ha ett projekt per kund?
Många gånger görs ändringar och tillägg i koden som gäller alla/flera kunder och min tanke var att undvika att behöva gå in i flera olika projekt och göra samma ändring.
Men din tanke med generella klassbibliotek är väldigt intressant. På så vis kanske jag kan ha ett projekt per kund men ändå komma från problemet jag nyss nämnde.

Applikationen jag bygger är GUIet varifrån användaren styr vår produkt. GUIet är snarlikt för alla kunder. Men GUIet kan behöva anpassas för varje kund, dessutom anpassas också produkten som i sin tur kräver anpassning i GUIet.

En tanke jag har är att kod för alla ev. programfunktioner ska finnas. Men att jag sedan ska kunna aktivera enbart den kod som kunden betalar för. Om kunden i ett senare skede vill ha en funktion som en annan kund har så ska det snabbt och lätt gå att aktivera den funktionen.

----------------
Jätteintressant att läsa diskussionen om SOA och DDD. SOA är helt nytt för mig så det känns kul att få höra synpunkter från personer som har god koll.

sofia om det är winforms du pratar om,

kolla in det här http://www.lowendahl.net/showShout.aspx?id=117 det kanske kan inspirera till en lättrörlig lösning.

Intressant läsning! Ju mer man läser om DDD och framförallt ser lite konkreta exempel (med kod bla.) så känns det fräscht. Dock väldigt abstrakt och på gräsen till IT-nörderi på vissa ställen ;)

Ni som har koll på hur andra jobbar. Hur vanligt är DDD bland konsulter/systemutvecklare på företag etc.? Hänger universiteten på och "lär ut" även DDD, eller är det OOP som gäller fortfarande?

Patrik:

Tack! Superbra!!

Jonas, du pratar hela tiden om hur en SOA ger dig mer flexibla lösningar där information bara "existerar" och regler bara "funkar". Det du beskriver är en övergripande strategi för hur in arkitektur och din organisation av dina inforamationsöar skall se ut och hur information skall flöda där emellan.

DDD beskriver inte samma sak.

DDD beskriver /hur/ du får informationen att flöda, den beskriver hur du tar reda på vilken kod du behöver skriva för att få informationen att flöda, den beskriver hur du organiserar din kod för att få en så enkel och flexibel implementation av den lösning du håller på att implementera (och med implementera menar jag skriva kod). DDD som praxis lägger sig inte i om utsidan av det du implementerar är en tjänst, en webb applikation eller vad du nu har. DDD är intresserat av att förstå och skriva kod som kan fånga det problem som skall lösas.

Som ett exempel pratar DDD om vilka artefakter som skall skrivas kod för, vilka tekniker och möjligheter du har i OO språk för att på bästa sätt fånga problemet och skapa lösningen som du vill ha, och jag pratar lösning på KOD nivå, inte på hur information skall struktureras i ett Enterprise.

Ett väldigt praktiskt exempel som jag sitter med just nu.

Cornerstone har länge haft utvärderingar på papper, nu skall det digitaliseras. Utvärderingarna skall kommas åt från många olika platser och många olika applikationer skall nyttja dess information och potentiellt kommer vårt egna system bytas ut mot ett centraliserat MS system i framtiden.

Lösningen är att skapa en tjänst som tillhandahåller det. När tjänsten defineras så beskriver vi det flöde av information som kommer att krävas för att klara alla de scenarion som finns (en kravspec om du vill). När de kontrakten och scheman är definerade så börjar nästa steg, att definera implementationen av tjänsten, där kommer DDD in. DDD hjälper mig att fånga domänen, vad kommer att gälla kodmässigt och modellmässigt inne i tjänsten för att jag skall kunna lösa affärsproblemet. Vi definerar en modell utifrån den informationen tillsammans med den / de som skapat kartan för informationsflödet och de som förstår vad som måste göras (domänexperter). Modellen som sådan behöver sedan backup, en fristående modell gör ingen lycklig. Där kommer andra practices i DDD in som tex Repositories som är ett samlingsnamn gör en typ av DAL. Man kanske upptäcker att man vill göra kalkylerade beräkningar i tjänsten, där ramlar andra DDD begrepp in som strategy osv.

Det här är varför jag säger att när du pratar SOA vs OO så blandar du abstraktionsnivåer. DDD är inte en arkitektur utan ett förhållningssätt och ideer om hur man på bästa sätt skriver kod för det problem man står framför.

När det sen gäller att skriva klient applikationer så är vi tillbaka med andra typer av practices som Presentation model, som jobbar som ett översättande lager från informationen vi fått från tjänsten till kliententeknologins olika behränsningar och möjligheter. I samma exmpel som ovan så handlar "presentation model" i en av klienterna om att gifta samma data från två olika tjänster och göra den tillgänglig med en modell för databinding osv. Ett pattern som underlättar när jag jobbar med windows formulär mot flera och olikt strukturerade informationskällor.

Igen så har det med implementation, skriva kod, att göra och inte i hur du organiserar din enterprise.

BTW,

Om du är sann mot DDD och andra agile practices så jobbar du jättemycket med interface baserad programmering för att underlätta att implementationen av de "kontrakten" skall kunna bytas ut och injeceras. Titta gärna med på IoC och Dependecy Injection för det. Iden med IoC och DI är klart besläktat med de ideer som drivit from service kontrakt och löst kopplade implementarioner.

För det första så citerar du något jag inte sagt och för det andra så har jag aldrig påstått att SOA kan jämföras med OO. Jag har sagt att SO och OO kan jämföras och gav dej länken till Don Box förklaring av skillnaderna (som jag f.ö. skriver under på till 100%).

Det var DDD som jag ville jämföra med en SOA och det var så vi kom in på DDD. Senare hälften av tråden har ju mer handlat om vad DDD egentligen är. Så med den input jag nu fått undrar jag om den här liknelsen nedan kan stämma?

interface IObjectOrientedPatterns
{
// ...
}

class ObjectOrientedDesign
{
// ...
}

sealed class DomainDrivenDesign : ObjectOrientedDesign, IObjectOrientedPatterns
{
// ...
}

Det vill säga att DDD = OOD + patterns. Så om jag får tolka DDD så innebär det i sin implementation att slutresultatet blir en klassisk skiktad arkitektur med PL, BLL och DAL + DB. Designen bygger på att separerar domänspecifika delar från varandra och från icke domänspecifika. Även om det inte känns speciellt nytt och fräscht så kanske det finns ett behov av att paketera det under ett nytt namn ... vad vet jag.

Jag tror vi hade en annan tråd där vi diskuterade SoC. Vad jag menar nu är att DDD (om det nu var DDD du refererade till) inte leder till SoC utan snarare SoS (separation of skills). En sådan design effektiviserar alltså inte förändringsarbeten eller återanvändning som är den största utmaningen med mjukvara. Även om du inte vill jämföra SOA med DDD så går de inte att kombinera i min mening. En SOA har som främsta uppgift att motarbeta skiktade arkitekturer eftersom de skapar statiska applikationer.

Det förutsätter iofs att IBP har bidragit till att driva fram SO, vilket kan diskuteras. Ser snarare IBP som en vägs ände för OOP, även om IoC, Aspects, etc har tagit software development ytterliggare ett steg i fel riktning. Så angående släktskapet mellan IoC och SO anser jag vara obefintligt, men kanske är det sista generationen av släkten OOP och kusin till IBP vi ser i IoC.

SO är en helt ny paradigm för mjukvaruutveckling och förkastar komponent- och objektorienterad design där IBP hör hemma.

Ang DDD,
För det första så förväxlar du DDD med en 3-skiktad lösning ala win dna eller J2EE. DDD definerar inte "tiers" som i gammal hederlig komponentbaserad utveckling (MDA) den talar inte om vart du har dina distributionspunkter, den talar inte om några fysiska indelningar (dller, komponenter, statiska referenser och allt vad det innebär) utan den pratar bara om logiska indelningar i koden för att skapa en så flexibel, agil och lätteunderhållen kod som möjligt. Den pratar om vilken kod du behöver skriva för att lösa din uppgift och fånga affärsproblemen (och lösningarna) i kod. Den pratar om hur du undviker kodduplicering och hur du får re-use i din kod (alltså inte re-use över din arktitektur), en sån enkel sak som en policy:

ValidEmailPolicy.ConformsTo("bla@bla.se"); // (väldigt förenklad)

Är ngt DDD pratar om för att kunna återanvända valideringar av dina strängar i din implentation. Igen lokalt, inte över din arkitetur utan kanske över dina 2-4 operation contracts som behöver validera ngn sträng.

DDD är inte en arkitektur, det är koddesign som talar om hur du modellerar ditt nuvarande problem i kod. En sak som ofta återkommer i DDD är att "koden är modellen", så återigen, kod, kod, kod. Inte arktietkur, inte kompilerade artefakter, inte distributionspunkter, inte EJB packages, inte assemblys, inte COM+ komponenter och allt annat fysiskt som du blandar ihop det med.

Om du vill dela upp din kod i olika tjänster så finns det inget i DDD som motsätter det, om du vill ha en tjänst för varje repository eller DDD service class (som knyter samman allt i ett use case) du skapar så funkar det alldeles utmärkt i DDD.

Koden du skrev är arv och interface implementation. Det har inget med DDD att göra. DDD nyttjar arv och interface för att lösa vissa infrastruktur och koddesignproblem, som tex att aldrig behöver fundera på om min cache är en asp.net cache, en cache som använder operationcontext eller en cache som använder sig av en statisk dictionary utan allt jag har är:

ICache cache = CacheFactory.GetCurrentCache();
cache.Add("key", "obejct");

DDD är en samling principer, ideer och best practices för att använda objektorienterade språk som C# och Java för att skriva och underhålla kod.

Ang citat,
"För det första så citerar du något jag inte sagt och för det andra så har jag aldrig påstått att SOA kan jämföras med OO. "

Det är inte ett citat, det är den uppfattning jag får när du pratar om SOA. Det låter på dig som om SOA implementerar sig själv. Allt du behöver är lite kontrakt och lite informationsflöden sen skapar och underhåller resten sig själv.

Du menar alltså att det här är en bra lösning i en SOA:

WCF -> operation contract -> SqlDataReader -> databas

För varenda operation du tänker implementera? Hur hade du tänkt underhålla det? Hur hade du tänkt undvika kodduplicering? Hur hade du tänkt kunna vara flexibel när koden måste förändras?


Ang SoC,
så har du fel. Den länk du skickade var en typ av SoC där det man separerade var exekveringen av bussiness rules, och det är ju bra, men SoC stannar inte bara vid det scenariot utan är en mer grundläggande princip för att skriva kod i allmänhet, dvs den kod du skriver skall inte vara beroende av någon annan kod utan bara att operationen finns där och returnerar vad du behöver. Principen kallas också med ett annat namn "Single Responsibility Principle". Målet med SoC i din KOD-design (inte system-design som din länk visade) är att inte ha några statiska beroenden mellan olika delar av din kod utan bara ha beroende på fördefinerade operationer (interface tex). Den definitionen av SoC fanns långt innan BPEL ens var påtänkt.

Vad gäller iden om att skikt bara skapas pga av SoS så är det också fel. Man separera olika typer av kod inte för att olika människor skall kunna jobba med dem utan för att undvika kodduplicering, underlätta underhåll osv. Jag har ett DAL i mina projekt för att inte behöva skriva koden för att skapa och öppna en connection om och om igen. Jag bryr minte (Concern) om var min connection kommer ifrån jag förutsätter bara att den finns där när jag ropar på:

DAL.ExecuteCommand("delete from BPEL");

Jag vill inte springa till 100 ställen i min kod för att lägga till loggning om min jag får connection failure. Jag vill göra det i min ExecuteCommand metod och vips så får jag loggning rakt igenom min applikation/tjänst som nyttjar mitt DAL.

Så det är långt från SoS (eller ms har alltid pratat om hur fiffigt det var med win DNA att man kunde ha olika utvecklare på olika tiers, men det är inte huvudpoängen och stannar inte vid tiers) utan det handlar om att varje "Concern" skapar en abstraktion och döljer vad den egentligen gör. För jag bryr mig inte. Jag vill bara när jag ropar på ExecuteCommand att ett kommanod ska skapas, en connection ska kopplas och öppnas, kommandot skall exekveras och om allt går bra så är jag helt ointersserad av resten.

På precis samms sätt är jag ointresserad av hur cachen är implementerad i ovanstående exempel.

Grejjen med DDD, IoC osv är att man måste tycka att .net/java/ruby etc är rätt verktyg eller rätt plattform för att bygga dina tjänster / applikationer.

Om man tycker de plattformarna är bra så är DDD väldigt en samling väldigt bra principer för hur du skall skriva bra kod på de plattformarna.

Kolla wikipedia artikeln om SoC

http://en.wikipedia.org/wiki/Separation_of_concerns

Den definerar SoC precis så som jag gör och daterar principen till 1974. Jag vet inte om SOA eller BPEL fanns då, men jag tror inte det ;)

Hej

Jonas, det du pratar om låter väldigt abstrakt för mig. Det som jag blir påmind om är något exempel om processer och entityservices som jag läst på MSDN, men dessvärre så fanns det ingen kod att studera.

Jag har nog samma syn på SOA som Patrik och därför skulle det skulle vara väldigt intressant och se ett exempel på kod som du anser vara SO/SOA.

btw, termen IBP, vad betyder det?

/patrik

"DDD är en samling principer, ideer och best practices för att använda objektorienterade språk som C# och Java för att skriva och underhålla kod."

Det var precis det jag menade med mitt kodexempel som inte var tänkte att beskriva hur DDD implementeras utan hur DDD kan beskrivas med en kodmetafor. DDD ärver OOD som designprincip och implementerar ett antal OO-patterns.

"Det är inte ett citat, det är den uppfattning jag får när du pratar om SOA."

Du använde dig av citationstecken. Därför tolkade jag som om du citerade mej.

Angående påståendet "Allt du behöver är lite kontrakt och lite informationsflöden sen skapar och underhåller resten sig själv." och ditt exempel på exponering av en SQLDataReader så kan jag inte relatera till det. Det har inget med det jag sagt eller vad SOA har med att göra. Beskriv gärna vad du menar med "WCF -> operation contract -> SqlDataReader -> databas" och hur du relaterar det till SOA eller vad jag sagt om SOA.

När det gäller skiktade arkitekturer så anser jag, precis som jag skrev på bloggen, att det absolut inte tillför något för att bidra till möjligheten att förändra applikationen rent funktionellt med tiden. Däremot kan man underlätta mer tekniska förändringar som har med applikationen och kringmiljön att göra:

* Applikationsserver - ex. ändra från IIS till Apache/Tomcat
* Databasserver - ex. ändra databasserver från SQL Server till MySQL
* Protokoll - ex. ändra kommunikationsprotokoll mellan logiska enheter i systemet
* Plattform - ex. flytta applikationen från Windows till Linux
* Hårdvara - ex. göra en tech-refresh av hårdvaran
* Säkerhet - ex. man vill göra applikationen åtkomlig över internet
* Dimensionering - ex. lyfta applikationen från 100 användare till 10000 användare
* Integration - ex. att man vill exponera funktioner och dataåtkomst via API:er
* Utökning - ex. bygga in nytt klientstöd för PDA:er och mobiltelefoner

De funktionella förändringarna underlättas inte alls av skiktade arkitekturer som ex:

* Regler - att kunna göra tillägg och förändringar av villkor i systemet som representerar affärsregler
* Processer - att ändra sekvensen av aktiviteter i en affärsprocess
* Information - att göra tillägg av nya informationsfält i den existerande datastrukturen
* Resurser - att i systemet ändra från att använda en viss resurs/tjänst till att använda en helt annan
* Händelser - att i systemet kunna hantera händelser som inte var påtänkta från början

Det är de funktionella domänrelaterade förändringarna som jag menar har att göra med SoC, inte de tekniska.

Björn Johansson:

DDD är vanligare än vad man tror, eller liknade sätt att designa sina apps. När jag pratar med folk om DDD etc, så säger måga systemutvecklare/arkitekter "men det är ju nästan precis så vi gör idag". DDD blir vanligare och vanligare även bland .Net utvecklare. Skolar lär inte ut DDD vad jag vet, utan håller sig till OOP. DDD är inte IT-nörderi, eller!? ;)

Det pratas mer och mer om att skapa entiteter, domän modeller (model-design first) etc. Microsoft kommer med ADO.Net Framework nästa hår som kommer hjälpa oss att skapa våra modeller och koppla dom mot olika datakällor (påminner mkt om OR-Mappning som används mkt inom DDD).

Här har du en länk till en sida om DDD: http://www.domaindrivendesign.org

/Fredrik Normén
MVP
blog: http://fredrik.nsquared2.com

Jag hävdar fortfarande att DDD inte är skiktad arkitektur, det är logisk uppdelning och design av din kod.

Vad gäller WCF - Operation Contract - Data Reader - Databas så menar jag att du pratar och disskuterar på en nivå som är främmande för DDD. Du pratar om hur tjänster och applikationer skall organiseras i en enterprise, hur tjänster är den nya sortens separation.

Men DDD handlar om det som är bakom separationen, inte det som definerar separationen.

Eftersom du inte vill tala om hur du tycker tjänsterna i en SOA skall impleteras och du vänder dig mot implementation baserat på DDD så antar jag att du tycker följande är en vettig kodimplementation av en tjänst i SOA (förutsätter en RPC stil, jag föredrar Document med data contract men det här är snabbare att skriva i ett foruminlägg) (obs, jag gissar att koden inte kompilerar det är bara proof of concept):


[ServiceContract]
public interface IOrderServiceContract {
[OperationContract]
public int CreateOrder(DateTime orderDate, int customerId)
}


public class OrderService : IOrderServiceContract {

public int CreateOrder(DateTime orderDate, int customerId) {
SqlConnection connection = new SqlConnection("");
SqlCommand insertProductCommand = new SqlCommand("insert into orders(orderDate, customerId) values(@orderDate, @customerId); SELECT @id = @@Identity", connection);

insertProductCommand.Parameters.Add("@orderDate", orderDate);
insertProductCommand.Parameters.Add("@customerId", customerId);
insertProductCommand.Parameters.Add("@id").Direction = ParameterDirection.Output;

try {
connection.Open()
insertProductCommand.ExecuteNonQuery();
}
finally {
connection.Close();
}

return Convert.ToInt32(insertProductCommand.Parameters["@id"]);
}
}


Vad gör du när du har 100 sådana är operation contracts? skapar connections i alla 100? Skapar parameterar manuellt för allihop?

Eller skulle du föredra att få det centraliserat på en plats så att du bara skriver koden en gång och sen ändrar lite i den bara?

Som tex, en förenkling:

public int CreateOrder(DateTime orderDate, int customerId) {
int result = OrderFactory.CreateOrder(orderDate, customerId);

return result;
}


public static class OrderFactory {
public static int CreateOrder(orderDate, customerId) {
Dictionary<string, object> parameters = new Dictionary<string, object>();

int result = DAL.ExecuteInsertAndReturnIdentity("Orders", parameters)

return result;
}
}

Koden ovan är inte DDD men den följer liknande principer som DRY och SoC.

Det här är i alla fall en del av essencen i DDD. Att strukturera din kod. Om jag nu bestämmer mig för att börja logga (funktionella förändringar som du kallar det) så kan jag göra det.


Vad gäller regler, processer, händelser osv så finns det alldeles utmärkta ideer för hur man skall implemntera dem föränderliga i DDD också. Utan att använda en flödesmotor ala BPEL, för jag antar att det är vad du lurar med under ytan. Det finns alldeles utmärkta sätt att skriva kod som hanterar de förändringarna. Igen pratar vi implementation i insidan av en tjänst. inte utsidan.

Likaså finns det bra riktlinjer för hur du använder tjänster och hur du separarer dem från din övriga kod för att, som du menar, kunna byta ut dem mot en annan tjänst. Så länge kontraktet är densamma.

DDD handlar om kod, hur du använder kod för att skriva tjänster och applikationer med C# och Java. Om man inte vill använda C# eller Java så finns det säkert andra plattformar och verktyg du kan använda.

Patrik, IBP - Interface Based Programing

Om du läser wikipedia artikeln igen, så ser du att orginaldefinitionen av SoC inte gör ngn skillnadn på tekniska och funktionella krav. SoC är en princip som du applicerar på alla aspekter i din applikation / dina tjänster och inte förbehållet regler och processer.

Patrik L,

Det är helt riktigt att SOA inte beskriver hur man organiserar sin kod i implementationen av den tjänsten du har där. Jag köper ditt resonemang om DDD ifall det hjälper dej med ett pattern för det exempel som du visade på. Vad en SOA däremot skulle kräva av din service är att den är registrerad i ett repository för återanvänding, att den används via ett mediation framework (ESB) vars uppgift är att virtualisera användningen av den fysiska tjänsten som du implementerat där. Det medför att flera andra tjänster kan nyttja din tjänst som en del av sina egna.

Tjänster kan bland annat nyttjas från BPEL (service orchestration) som du nämner. Men BPEL är inte SOA, det är en killer application för SOA. Att nyttja tjänster som i sin tur blir nyttjade av andra tjänster kallas en SOA, dvs det nätverk av tjänster som ersätter den paketering av funktion och information som klassiska applikationer är idag.

Ja,

och DDD varken hjälper eller stjälper dig för att använda ESB eller service repositories. DDD bryr sig som sagt inte om ytterkanterna utan utan fokuserar på insidan.

Att bygga applikationer utifrån domänen först känns ändå rätt logiskt/praktiskt. Men ofta så har man ju en relationsdatabas i botten. I "vanliga fall" har, i alla fall jag, hittills byggt både en databasmodell och en objektmodell (för affärslogik).

Avser man med DDD att hoppa över steget med att skapa en databasmodell eftersom domänen kommer avspegla databasen? Hur får man till en normaliserad (till typ 4-5 grad) databas med DDD tänket då?
Jag anar iofs vad svaret kan bli här...och bygga en helt nytt system/applikation med DDD-tänk där en helt ny databas ska skapas kommer funka.

Ett scenario som kan förekomma är ju då man redan har RDBMS sedan 10-20 år tillbaka men man vill ha en ny applikation/applikationer/webservices runt den befinliga databasen och dess information.
Kommer man även då kunna utveckla med DDD-tänk utan att röra den befintliga databasmodellen?

Scenarion där du har en gammal databas är det väldigt viktigta att börja med modellen först-

Anledningen till det är att i databasen är en massa trade-offs gjorda (dels normaliserigar) för tidigare scenarion och tidigare applikationer. När du modellerar din nya applikation vill du inte ha de begränsningarna i din modellering som det innebär.

När du väl skapat din modell, då kan du börja titta på (i legacy fallet) hur du faktiskt mappar modellen mot relationsdatan.

I fallet ny database / nya tabeller så är det efter du skapat modellen som du först då tittar på hur du bäst lagrara datat. DDD definerar inte hur lagringen skall se ut. Det är tom så att DDD säger att du inte skall tänka på lagring förräns du verkligen behöver det, och då inte förutsätta att en databas är bästa stället.

När det sen gäller lagringen så är det upp till en DBA att skapa den mest effektiva lagringsmodellen, men eftersom den mest effektiva lagringsmodellen (relationsmodellen) och den mest effektiva modellen för att uttrycka affärsproblemen ( objekt) inte matchar så kommer det finnas en miss-match här.

Men det är väldigt viktigt att objektsmodellen så lite som möjligt får inflytande över hur saker som sparas, lika mycket som relationsmodellen får så lite inflytande som möjligt för hur saker modelleras. Det går inte att undvika att man måste ta hänsyn mer eller mindre, men utgånspositionen måste vara att de inte får påverka.


Ett exempel som jag ofta pratar om när det handlar om det här är Many-To-Many.

Om jag pratar affärsdomän med en affärsexpert så säger han tex:

"En order kan ha många produkter, en produkt kan tillhöra många ordrar"

I domänmodellen så kommer det se ut ungefär så här:

public class Order {
public int Id;
public List<Product> Products;
}

public class Product {
public int Id;
public string Name;
public List<Order> Orders;
}


och det (i en box modell inte kod) kommer vara helt naturligt för affärsexperten. "Ja precis så".

Men om vi tittar på hur man så effektivt som möjligt modellerar det enligt relationsmodellen så ser det ju ut ungefär så här:


Table Products:
--
Column Id
Column Name

Table Orders:
--
Column Id

Table ProductOrders
--
Column ProductId
Column OrderId


Hur väl representerar tabellen ProductOrders en artefakt i affären? I bland kanske det är viktigt, då kallas den ofta OrderLine, ibland inte. Vilket som är det här ett exempel på. ProductOrders säger ingenting i affärens process, den känner bara till den tidigare modellen.

Däremot så krävs det för normalisering och för att persistence skall bli så effektiv som möjligt.

(BTW DDD har också ideer om nycklar, det jag gjorde nu var en kort genväg, egentligen skall man skilja på persistence nyckeln (som identiferar databasraden) och affärsnycklen som identifierar objektet i verksamheten)

DDD == How to build a O/R-mappare, rätt och slätt!

Så om jag laddar ner en sådan, behöver jag tänka på DDD då, eller påverkar det mer än implementationen till slut ändå?

Patrik, jag förstår om det är krångligt att förklara DDD. Jag har lyssnat på tidigare försök där smartare personer än jag frågat ut DDD experter och förvirring är ett under statement. Länkarna finns ovan ...

Det krävs mer än ett forum att förklara DDD, men DDD != hur man bygger en OR-Mapper (vet att du va ironisk där).. En OR-Mapper kan du använda om du köra OOP, eller om du helt enklet bara vill mappa object (villka som) mot en rellations-databas. Se på ADO.Net Entity Framework, som mer eller mindre är en mapper där du kommer kunna bygga upp din modell först och sedan mappa mot olika källor. Du kommer då kunna använda LINQ som ett Query Language istället för tex HQL som Hibernate använder idag som är en av de mest sofistikerade OR-Mappers inom Java världen. Varför går ADO.Net Teamet mot att södja mer och mer model-first!? Jo för det är stor efterfrågan på det. Det är ett skält till att Entity Framework blir uppflyttat till år 2008.

Vill man få en grund till DDD så är Eric Evans bok bra, sedan för att se på lite implementations tips och tankar etc, så har du Jimmy Nilssons bok.

Sedan kan du alltid ta en öl (fast jag föredrar Cola) tillsammans med mig och Patrik en vacker kväll i fina Sthlm, speciellt nu när jag har blivit en 08:a ;)

/Fredrik Normén [MVP]
blog: http://fredrik.nsquared2.com

Eh, vad i det jag skrev säger att DDD är en ORM? DDD definerar inte Data Mapper patterns, det finns andra som gör. DDD berättar inte hur du skriver ramverk utan hur du skriver kod för ditt domänproblem. DataAccess är aldrig intressant för domänproblemet.

Det finns inget i DDD som berättar hur du accessar data på bästa sätt. Där ORM är ett sätt, det finns de som lyckosamt implementerat DDD med DataSet.

En O/R-mappare som enbart hanterar data access, finns den?

Vad är det för kod du nämner som ska lösa mitt domänproblem och vad är domänproblemet?

Jag tycker mest ni pratar om vad DDD inte är, när ska DDD beskrivas?

Apropå Evans bok så bläddrade jag lite i den alldeles nyss. Där finns ett stycke om vad en "good service" karakteriseras där tredje punkten säger att den skall vara tillståndslös (stateless). Med det menar han att en klient kan använda vilken instans av en tjänst utan hänsyn till instansens tidigare historik.

En tjänst som exponerar en lång transaktion (ex en faktureringsprocess som tar veckor) skulle alltså vara en dålig tjänst, eftersom den är tillståndsfull under tiden den exekverar?

BTW. Här är jag ensam och fajtar två stycken MVP:er ... hjälp mej någon! ;)

NHibernate handhar bara dataacess.

Alltså ORM är istället för SqlDataadapter och SqlCommand. Den låter mig använda Product och Order klasser istället för Product och Order rader i ett DataSet.

Vissa ORM har tjänster som underlättar olika scenarion, som tex Lazy Loading/Load Spans, Inverse Management, Cache osv. Men alltihop handlar om infrastruktur tjänster, automatisering av saker som du inte skall behöva implementera själv. En abstraktionsnivå.

Den enda påverkan en ORM har på design (och bara på design av kod, inte arkitektur, skiktining eller ngt annat sådant) är att du processar data med object istället för DataSet. ORM är varken mer eller mindre.

Vi har beskrivit DDD, men du köper det inte utan försöker hela tiden applicera andra begrepp på det, gärna arkitekturella. DDD handlar om design av kod, det handlar om hur du tar verksamhetskrav och uttrycker det i den kod som måste till för att ngt faktiskt skall exekveras och något faktiskt skall göras. Det kan tex vara informationsflöden från en tjänst, vilket jobb behöver jag faktiskt göra för att arkitekten skall få sin information och rätt dessutom. Mer exakt handlar det om hur du strukturera din C# (eller Java kod) för olika implementationsscenarion du stöter på, som tex återanvända validering i din kod. DDD pratar också mycket om att ha ett gemensamt språk med verksamheten så att när jag skall skriva min kod, pratar i samma termer som verksamheten för att dels förklara hur jag tänker när jag gör implementationen men också för att verksamheten tydligt skall kunna tala om för mig hur deras problem fungerar. Med ett sådant språk blir det lättare att göra avstämningar på vägen för att se om man fångat verksamhetens detaljer på rätt sätt i koddetaljerna.

När Evans pratar om att en bra designad tjänst är stateless så pratar han om idealet. Ur många perspektiv (skalbarhet och testbarhet är de två viktigaste) så är den absolut bästa tjänsten snabba meddelanden, in och ut. Men omständigheterna råder. Om verksamheten kräver long running transactions så gör den det, det betyder inte att den ur ett tekniskt perspektiv blev speciellt mycket mer skalbar, effektiv eller testbar, men du behöver den därför skriver du den.

Vi kanske inte ska dra igång en ORM-diskussion här också ... det finns andra som beskriver konsekvenserna av O/R-mapping bättre än jag kan göra, se http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Jag får en känsla av att DDD förespråkar code happy programmers, lite cowboy utveckling alltså. Lyssnar man till Evans och Nilsson så återkommer de ständigt till att man inte ska vara rädd att börja koda så tidigt som möjligt, för man kan alltid göra om det ifall det blev fel. DU säger även att DDD handlar om att ta verksamhetskraven och omsätta dom i kod. Pang på rödbetan alltså, Zero Design.

Jag får även en uppfattning att DDD enbart resonerar om informationsflöde (domän-information) när det gäller kommunikation med tjänster. Det kanske beror på att DDD just bara behandlar domänmodellen som ett entitetslager?

Ang stateless services så måste jag säga att är det något som verksamheten kräver så är det long running services. En fråga; finns det något annat än long running services som en verksamhet är bekant med?

Jag håller inte med Ted, som jag skrivit om innan på min blog. Han har fel om ORM och det beror på att han inte förstår dem och inte har jobbat med dem. Det lustiga med honom är att han tycker ORM suger men att objektorienterade databaser är rätt. OODB är ju om något ett vietnam, varje vecka kommer det en ny OODB som löst prestanda problement, men så visar det sig att det fortfarande är ett javaprogram som körs inproc.

Ted har gjort mycket bra för communityn, men i den här frågan behöver han mer kött på benen (tex använt ORM i ett projekt) innan han uttalar sig.

Jag har jobbat med ORM i flera år, det påverkar inte hur jag skriver applikationer utan är ett verktyg som underlättar för mig att skriva applikationer som jag vill ha dem.

DDD förespråkar mycket kod, av den enkla anledningen att du förr eller senare ändå behöver skriva den för att få något gjort. Lika bra att göra det tidigt och få feedback direkt än att göra det sent och långt in i projektet få skriva om.

DDD pratar inte om Zero Design. Däremot tror man inte på "Big upfront design" i DDD. Av erfarenhet så vet man att genom projektet så lär man sig mer och mer om problemdomänen och får förståelser som ofta helt ritar om den karta som man gjorde från början. Och när jag pratar karta så är det igen kod, inte arkitektur/informationsflöde jag pratar om. Med andra ord man räknar med att den mänskliga faktorn med kommunikationsproblem existerar. I princip varje projekt jag suttit i som jag inte själv varit domänexpert så har det alltid sent i projektet kommit fram ngt som verksamheten säger "jaha, men det trodde jag var underförstått"

Jag fortsätter, vet inte riktigt vad som hände, den posta sig själv mitt i,

Vad gäller informationsflöden så får du gärna utveckla lite för jag är inte riktigt säker på att jag förstår vad du menar.

Men det är rätt att domänmodellen i DDD är ett entiteslager, gärna ett rikt sådant som objectshiearki Order.OrderLines osv. Runt det entitslagreat skapar man sedan olika "tjänster" (inte i samma termer som soa tjänst) för att tex validera domänen, skicka den till persistence, bygga objects träden osv. Som matchar väl mot hur verksamheten ser på det aktiva steget i en process. Rent handfast handlar det tex om att inte låta en order ha dyrare orderlines än aggregerat 100 000, osv. Det här är vad jag menar när jag säger fånga domänen. En domän är ett verksamhetsområde, tex ta emot, processa och sedan skicka ordern vidare för skeppning. När jag i DDD implementerar det så försöker jag fånga all de detaljer som verksamheten har vad gäller just den subprocessen i min kod så att när ordern kommer in, så genomgår den vad den behöver innan den sedan (om den ska det) skickas vidare till ngn / ngt som processar skeppningen.


När du pratar tjänst så menar du process gissar jag, för jag kan räkan upp mängder av tjänster som rent tekniskt inte är longrunning. Det är vad Evans pratar om, inte att man ska undvika verksamhets processer som när de uttrycks i tjänster är long running, utan att implementationen av tjänsten skall vara så stateless som möjligt. Jag är lite osäker på exakt vilket påstående du referrerar till, men om du har en tjänst med long running så brukar i DDD rekommendationen vara att skicka den från den direkta tjänsten in i en state machine av något slag för vidare processning.

DDD har visst svar på det mesta, men att förklara det är desto svårare. Jag har i ditt resonemang förstått att det handlar om att fånga domänmodellen (ett entitetslager) tillsammans med domänexperten genom att prata ett språk som gör att båda parter förstår varandra. Dessutom finns det ett antal patterns som kan användas för att effektivt implementera domänmodellen mha objektorienterade språk. Jag har även fått det bekräftat att ge sig på kodningen snabbt för att få feedback är väsentligt.

Några frågor:

1. Detta universellt magiska språk som man talar med domänexperten för att lösa upp alla kunskapsmässig, kulturella och övriga kommunikationsproblem; tar man fram ett nytt för varje domän, varje domänexpert, projekt eller finns det ett generellt språk för alla DDD-sammanhang?
2. Domänmodellen som man projicerar kraven på skall alltså implementeras som ett entitetslager, är det dess ingående artefakter du refererar till som god Separation of Concerns (SoC)?
3. Om man nu har ett språk som undanröjer missuppfattningar mellan kunden och utvecklare, varför kan man då inte designa lösningen först utan att kasta sig på koden direkt? Det känns motsägelsefullt ...

Ang stateless services så skulle jag gärna vilja höra vilka som av verksamheten kan betraktas som icke long running. Det var en intressant separation du gjorde mellan tjänsten och tillståndsmaskinen. Jag tror du får svårt att prata med en domänexpert om tjänster ifall du gör den uppdelningen. Går du ned på processnivå på CPUn så tror jag du tappar kunden rätt fort.

1) Det språket är per domän, DDD pratar om hur man kan destillera det i projektet inte vad man ska ha för språk.

2) SoC är en övergripande princip inget speciellt för domänmodellen.

3) Därför att språket växer fram under projektet. Det är inte så att man sätter sig ner och säger "nu tar vi fram ett gemensamt språk" utan det växer fram allt eftersom fler och djupare detaljer blir tydliga vid disskusioner om domänen.


Ang long running, Nej du har helt i det du säger. Men vad jag försöker säga är att när Evans pratar om service i sin bok så pratar han inte om processen utan om implementationsdetaljer. Det är information till utvecklaren som skriver koden, ungefär som att säga att "när du sparar datat så gör det i en databas mha ado.net" men det tar man inte upp med verksamheten det heller utan man säger på sin höjd att datat ligger i en databas.

DDD har flera sektioner, en talar om hur man så effektivt som möjligt får informationen man behöver från verksamhetsexperterna, en annan talar om hur du sen omvandlar den information du fått till kod. lite som "interface mot kund" och "kod i projektet". När du läser Evans bok så får du läsa den som utvecklare, inte som arkitekt eller kravställare för de är mottagare av alla de ideer som evans pratar om, inte användare.

"Jag har även fått det bekräftat att ge sig på kodningen snabbt för att få feedback är väsentligt. "

Feedback här är lite luddigt. Om jag börjar kod direkt så kommer jag kanska fort upptäcka omdråden där jag kanske inte riktigt förstod, eller som verkar underliga, eller upptäcker hål i det jag trodde jag visste som blir väldigt tydliga när jag försöker skapa något runt informationen. Då får jag möjlighet att ganska fort gå tillbaka och samla mer information.

Till skillnad från en vattenfallsmodell med BUFD med "Specificakation in, mjukvara ut" tänket.

Jag har läst att det viktigaste med DDD är att hålla fokus på domänproblemet. Att inte låta sig distraheras av andra saker som är mer tekniskt relaterade och det gäller att koden är så nära abstraktionen som möjligt.

Jag tycker att den situationen som beskrivs här är vanlig när man jobbar med modeller, verktyg och språk som skapar den typen av distrahering. Alltså där modellen och språket skiljer sig från verkligheten och där varje krav måste tolkas ned i implementationen.

Ja, DDD definerar det du pratar om i två delar. Det ena är domänen, dvs modelleringen av problemet, det andra är infratruktur, dvs teknik som "hur accessar jag data".

objekt är idag det närmaste jag känner att jag kan komma vad gäller att få verkligheten att spegla sig i min kod. Det är främst den mognaste varianten. Sen tycker jag att andra initiativ som DLSer osv är intressanta, men de är långt från mogna och innan de är det kommer C# vara den tekniska plattform jag använder, det innebär objekt som representation av problemet och där är DDD ett väldigt bra hjälpmedel för styring över hur jag kommer så nära lösnigen som möjligt.

Angående Agile Development så bottnar det i grunden i att leverantören och beställaren inte förstår varandra och därför så kortar man ned leveranscyklerna och tar det där ifrån istället. Vattenfallsmodellen o a s utgår ifrån att leverantören känner sina egna verktyg och har kunskaper i beställarens "domäner".

C# och verkligheten befinner sig långt från varandra. Objekt kan komma närmare, men kan vara oerhört fel att närma sig verkligheten med hjälp av. Allt kan inte objektifieras och gäller det verksamhetsstöd så är det ofta helt felaktigt att ta den vägen. Detta sätt att angripa implementationen kallas för objektorientering och skapar ett informationscentriskt tänkande. Det kan även kallas för bottom-up design därför att det utifrån informationen bygger ett användningsområde.

Visst handlar det om att i systemet representera information som förekommer i verksamheten. Men informationen måste kunna härledas. Det sker genom att finna behovet av informationen. Behovet av information kommer från processerna i verksamheten. Top-down design handlar om att på samma agila sätt implementera processerna och lämna informationen där hän. Informationen kommer att under projektets gång förändra sig med största sannolikhet och det är inte av intresse för det pågående arbetet.

Jag vet att DDD inte säger att man ska kasta sig över informationsmodellen utan försöka härleda den från processer, bland annat. Men saken är de att har man en objektorienterad bakgrund så hamnar oftast i den situationen. Det är också av den anledningen man hamnar i refactoring väldigt tidigt i projekten. Det sägs att man inte ska vara rädd för refactoring inom DDD. Men fråga den som beställer vad han tycker och om han sover gott om nätterna när han ligger vaken och undrar om projektet förstod vad han sa vid den här iterationen. Hur många iterationer ska det ta innan det sitter, hur många nätter ska beställaren ligga vaken?

Jag ska svara mer utförligt sen men det du aldrig har sagt är hur du tycker att man bättre representerar relationen mellan Order och OrderLine än med:

Order.OrderLines

Som datarepresentation i ett punktnoterat språk är det väl ok, men det kan skrivas i SQL, XPath, XQuery, etc. Men det jag menar är att det inte är intressant i den initiala designen, hur informationen relaterar till varandra i domänen. Ännu mindre intressant är det hur datat representeras. Det intressanta är hur den ska användas, av vem, när och i vilket sammanhang. För att få dom svaren måste man ge sig på affärsprocesserna som ska automatiseras. Precis som DDD förespråkar för objektmodellen tycker jag är rimligt att förhålla sig till processmodellen. Dvs att "kasta sig" in och "koda" processen mha verktyg och språk som är ämnade för det (dvs inte C# och Java). Verktyg som är till för att implementera, kontrollera, mäta och refactorera processer. Processerna är kärnan i systemet, men de syns oftast inte eftersom de aldrig kan visualiseras i en klassisk applikation byggd mha OOD eller DDD. Ett problem med en traditionell design är att informationens olika tillstånd i processen representeras som kolumner och fält i en databas och en objektmodell. Det skapar ett väldigt statiskt beteende i systemet på sikt, kanske inte inom projektets tidsramar men efter ett tag. OOD skapar statiska applikationer.

Jonas:

Jag va ute på ett uppdrag där vi körde Agile på Stena Line. Vi tittade på affärs-processerna och en del process var tex att kunna efter en beställnig skicka ut request till olika leverantörer och få svar för att godkänna requesten, och sedan se till att beställaren fick ett ok på sin bokning eller inte (finns massor av regler och annat som definierades och bestämmde hur processer skulle starta andra och vilken väg den skulle ta etc). Det fanns en tydlig start på processen och ett tydligt slut. Jag va den som implementerade detta. Tyvärr fanns det inte verktyg i projektet för att rita processer diagram etc, tex efter BPML standarden, som en process motor hanterade. Men det fanns stöd för att starta processern med eventsystem och arbetflöden, men flödet krävde viss kodning för att fungera (men det är en helt annan sak). Villket fall som, så själva request hanteringen implementerades med hjälp av DDD (Request hanteringen blev en "tjänst" som är med i processen).

En fråga har du varit med i ett agilt projekt någon gång ute i "verkligheten"? Ett tips, ring Stena och fråga va de anser om agile vs vattenfallsmodellen, efter att ha kört vattenfallsmodellen i flera år och nu sakta går över till agile. Fråga vad som levererade bäst resultat, kvalitet, och vilken modell som gav de förväntningar beställaren hade från start etc. Jag tror du kommer bli förvånad ;)

/Fredrik Normén [MVP]
blog: http://fredrik.nsquared2.com

Fredrik,

Du säger ju massa kloka saker fram till dess du nämner att du implementerade allt med DDD. Du nämnde leverantörsprocessen där ni definierade regler, flöden, händelser mm. Det är ju exakt det jag säger att kraven oftast utgår från. Att då omsätta det i en domänmodell á la entiteter och dess relationer för att sedan förkasta processen är ju en svaghet i objektmodellen och objektorienterad design, som DDD ärver. Ta istället processen och implementera den i ett processverktyg (BPMS) och låt objekten, datamodellen och entiteterna vara. Låt sedan processen styra behoven över datamodellen och GUI. Normalt sätt så bygger man alldeles för komplexa lösningar för en domänmodell och GUI när man arbetar enligt objektorienterad design. Det blir objekt som inte gör annat än skyffla information mellan lager och dialoger som inte används.

Vad är numret till Stena Line ;)

Jag sa inte att jag har implementerat allt med DDD, jag sa att "tjänsten" som hanterar request är implementerad efter DDD och "tjänsten" är en del i processen. Kan hålla med om att den "tjänsten" är statisk och inte dynamisk, men jag kan i min process enkelt byta ut den tjänsten mot en annan eftersom den triggas av ett event. Sjävla request "tjänsten" skulle kunna blivit mer dynamisk om man skapa den som en innre process. Men det måste finnas verktyg och kunskaper i organisationen också. Man får även tänka på den roganisation som finns, tex det kommer och går folk (konsulter), de ska lätt kunna sätta sig in i ett systemet och det är inte många konsulter och utvecklare idag som tänker "process"-orienterat på den nivå som du eller kan hantera verktygen. Pga av det och många kriterier så tar man till andra lösningar. När det kommer till implementation av "statiska" applikationer, där ett UI behövs, databas för lagring av data etc, så tycker jag att DDD är en modell som passar mig perfekt. Du kan inte genom att definiera processer enkelt i dag skapa ett användergränsnitt med flikar, paneler, kontroller av olika slag och positionera dom som beställaren vill samt lagra information i en datakälla etc (eller!?). Men du kan underlätta och skapa processer som klienten kan utnyttja för att skapa underliggande dynamiska "tjänster". Men något måste starta processen, något måste via input data från en användare, få ner det till datakällan etc.

Ett exempel där DDD passar in, tex en Windows app som ska presentera en bokning, där användaren ska kunna förändra bokingen med hjälp av olika input-kontroller. Bokningen representeras i en entitet med agregat och value objects etc. Du vill tex beräkna priser etc utifrån den information som din entitet bär, och implementerar den logiken i din entitet för den har ändå informationen för att kunna göra beräkningen av tex vad kostar resan mm. Du binder din entitet mot ett UI och skickar vidare din entitet för lagring vid ändring av informationen. En OR-mapper kan användas för att fylla entiteten med information och hantera UoW, Identity Map, change tracking, mappa entiteten mot en rellationsdatabas. Sedan när användaren gör en confirm, så kan underliggande processer startas (om det behövs) för att hantera bokningen. Men för att underlätta underhåll av klienten etc, så används tex DDD. Där object definieras och försöker representera ett verkligt ting för att skapa en mer logisk bild av en bokning med hjälp av kod. Tex så är: booking.BookingNumber enklare att läsa och förstå i kod än att tex använda sig av XPATH etc. Det handlar om att skriva kod som andra kan förstå, där det ska gå så snabbt som möjligt med ögat se och förstå vad som händer.

/Fredrik Normén [MVP]
blog: http://fredrik.nsquared2.com

När man kommunicerar tjänstebegreppet med en kund så tror jag det är viktigt att man inte ser tjänster som bara tunna interface utan som en helhet, dvs inkl hela implementationen. Ta exempelvis en orderprocess som startar med en ny order och slutar då varorna är betalda och levererade. I kundens ögon så kallar man det en tjänst att hantera en process. Som du vet så ingår det ett antal operationer (wsdl-definition) i en tjänst, rent tekniskt alltså. Så kan även en kund se på saken eftersom orderprocessen måste kunna hantera, inte bara 'skapa en ny order', utan även cancelera ordrer, ändra order, etc. Alla dessa operationer som ingår som kommunikationspunkter mot processen är alltså en del av tjänsten och det kan en kund förstå.

Det finns alltså en god relation mellan verkligheten och tjänstemodellen. Men framför allt så representerar man verkligheten väl i en processorienterad modell. I den kan man synliggöra hela diskussionen där det ingår start och slut för ordern, hantering av förutsedda och oförutsedda händelser, kompensering vid fel och felhantering, visualisering av alla aktiviteter, subprocesser, etc. Här finns alltså en modell och en implementation som ligger väldigt nära kundens förståelse för sin egen verksamhet, vilket gör det enklare att arbeta och krava i tidiga faser i ett projekt. Det gör också att man får in en flexibilitet som underlättar förändringar av tjänsterna och processerna.

Du nämner GUI vilket man i en processorienterad modell kan se som en förlängning av tjänsterna som är till för användare. Vissa tjänster konsumeras från ett GUI och av en användare, exempelvis cancelering av en order, andra konsumeras från andra processer eller system där användaren inte är inblandad. Hur man organiserar sitt användargränssnitt är en annan historia där det säkert finns bra lösningar och patterns som redan har hanterat det. Bygga GUI mha objektorienterad språk motsäger jag inte heller. OOD är en väldigt passande modell för knappar, tabbar, fönster, canvas, etc.

Du hade ett exempel på förändring av en bokning. Anta istället att man vill cancelera en order (vilket är jämförbart med ditt exempel) som tidigare lagts in i systemet via operationen skapaOrder i ordertjänsten. För att prata med processer så måste man använda en nyckel som är unik för den order man vill cancelera (ett vanligt orderId i det här fallet). Processmotorn har en viktig uppgift i att koppla anropet i tjänsten via operation mot rätt instans av processen (kallas Correlation) där order som ska canceleras finns. Notera att man måste gå via processen för att överhuvudtaget kunna förändra ordern. Det är därför man säger att processer är long running transations. Processen är som en transaktion som hanterar och kontrollerar förändring av ordern enligt ett förutbestämt mönster.

En viktig detalj är också att det orderId som man använder för att skicka in i canceleringen måste hanteras utanför processen. Det gäller även orderinformationen som tillsammans med nyckeln lagras utanför processmotorn i en persistent datahantering (ex RDBMS). Den datalagringen används på vanligt vis när man ska skapa listor, sökningar etc i ett GUI. Cancelering föregicks säkert av att ett samtal kom in till kundtjänst där personalen fick personnummer från kunden som han slog upp i datalagringen via ett GUI. Därefter fick han se alla order som kunden lagt och kunde därför resonera sig fram till vilken order han vill cancelera. Därefter kommer användaren av systemet att skicka orderId till cancelOrder i ordertjänsten. Operationen cancelOrder exponeras av processmotorn som kan koppla anropet till rätt processinstans och eftersom man in processen har definierat en oförutsedd händelse (man vet alltså inte när det händer i processen, men att det kan hända) så kommer processen att hantera efterspelet till en cancelering. Det kan exempelvis vara att kommunicera till andra processer som hanterat leverans och betalning så dom också vet att ordern har cancelerats.

Oj det blev långt inlägg, jag skriver en bok istället ... nu är det midsommar. Trevlig helg!

Nu pratar du igen om äpplen och päron.

Om du vill använda ett annat verktyg för att implementera dina tjänster så funkar det utmärkt. Men om du har .NET som verktyg så kommer objekt orienterad design av implementationen vara det du vill arbeta med i stort.

Om det sedan kommer andra, lika accepterade plattformar som .NET, som har ngn annan form av abstraktionsnivå så må det vara hänt. Men vi pratar om .NET och C# som verktyg här.

Det har gjorts massvis med försök att skapa verktyg som har den abstraktionsnivå du pratar om, inget har fått speciellt stor genomslagskraft. De har kommit och gått de senaste 15 åren fram och tillbaka. De har alltid fallit på att abstraktionsnivån blir för hög och för svår att göra ngt som inte de som byggde verktyget tänkte på från början.

Programmeringsspråk och generiska plattformar som Java och C# lider mycket mindre av de symptom som vanliga 4GL-verktyg (för det är vad det är) brukar stöta på.

Vad gäller att använda de mest populära utvecklingsplattformarna som finns idag, dvs C# och Java, då behöver du mappa ner processen i en domänmodell.

Ang dina förslag med SQL eller XML / XPath som språk för implementation av bussiness processes så hoppas jag du skämtar.

Patrik,

Tiderna förändras och jämför man framstegen som en utvecklare har gjort med vad mänskligheten har åstadkommit så representerar du i ditt resonemang en grottmänniska. Jag tror det är ganska symtomatiskt att just Du nämner Agila metoder för utveckling av programvara. Befinner man sig på den nivå du beskriver med den generiska plattform där allt är möjligt kommer komplexiteten alltid att kunna jämföras med att skapa hjulet på nytt i varje sammanhang. Agila metoder fokuserar på symptomen istället för orsaken av att utvecklare inte kan handskas med verkligheten eftersom man har så generiska verktyg till hands.

"Om du vill använda ett annat verktyg för att implementera dina tjänster så funkar det utmärkt. Men om du har .NET som verktyg så kommer objekt orienterad design av implementationen vara det du vill arbeta med i stort."

Vem talar du om när du säger att "du vill arbeta med"? Jag säger att det är just det man inte vill arbeta med om branschen ska lämna grottstadiet och röra sig framåt.

"Om det sedan kommer andra, lika accepterade plattformar som .NET, som har ngn annan form av abstraktionsnivå så må det vara hänt. Men vi pratar om .NET och C# som verktyg här."

Gör vi?

"Det har gjorts massvis med försök att skapa verktyg som har den abstraktionsnivå du pratar om, inget har fått speciellt stor genomslagskraft. De har kommit och gått de senaste 15 åren fram och tillbaka. De har alltid fallit på att abstraktionsnivån blir för hög och för svår att göra ngt som inte de som byggde verktyget tänkte på från början."

Jag vet inte vad du jämför med men processverktygen har redan och kommer framöver att få stort genomslag för både stort och smått. För .NET-utvecklare kommer WF spela en stor roll framöver och BPM har prognoser på 3 miljarder dollar nästa år. GUI kommer allt mer att styras av processer, dokument kommer att styras av processer, tjänster, etc också. OOD har snart kommit till sin vägs ände och det gäller även metoder som förknippas med detsamma (där vi har nämnt några av dom tidigare).

"Programmeringsspråk och generiska plattformar som Java och C# lider mycket mindre av de symptom som vanliga 4GL-verktyg (för det är vad det är) brukar stöta på."

Jag vill inte jämföra olika alternativa plattform för utveckling på en högre abstraktionsnivå. Olika verktyg har olika syfte, precis som med DSL'er. Så funkar det även i verkligheten där man använder olika språk, verktyg och plattformar för olika ändamål. De är nog bara utvecklare som av någon anledning vill sitta med ett enda språk som de ska kunna bygga allt med. Det är enligt utvecklare att ha kontroll över läget. Den sista kommuniststaten skulle vissa ha sagt …

"Vad gäller att använda de mest populära utvecklingsplattformarna som finns idag, dvs C# och Java, då behöver du mappa ner processen i en domänmodell."

Där nere gör den ingen nytta, lita på mej. För det första så syns den inte där och för det andra så har processen inget med domänmodellen att göra. Domänmodellen är plumbing i sammanhanget.

"Ang dina förslag med SQL eller XML / XPath som språk för implementation av bussiness processes så hoppas jag du skämtar."

Återigen så visar du på en dålig insikt i de krav på variation av lösningar som verkligheten ställer.

Ett tips till dej är att släppa sargen och åka ut på isen så ser du kanske saken från ett annat perspektiv.

"Agila metoder fokuserar på symptomen istället för orsaken av att utvecklare inte kan handskas med verkligheten eftersom man har så generiska verktyg till hands."

Du har fel om Agila metoder. Agile handlar bland annat om att kommunikation är svårt, att där finns "viskleken" symptom när information går från en person till en annan. Det är ett verkligt problem, inte något Agile världen hittat på för att "de inte kan handskas med verkligheten".

Agile som rörelse handlar om att sätta vissa aspekter i ett projekt före andra. Fyra väldigt grundläggande principer:

"Individuals and interactions over processes and tools "
"Working software over comprehensive documentation "
"Customer collaboration over contract negotiation "
"Responding to change over following a plan "

De säger inte att värdet till höger är oviktigt, bara att värdet till vänster är viktigare. Det är en ganska gedigen erfarenhetslista om man tittar på de som skrev under det första manifestet ( http://www.agilemanifesto.org/ ) med många år i din "verklighet".


Det handlar om att handskas med verkligheten väldigt handfast.

"Vem talar du om när du säger att "du vill arbeta med"? "

Jag talar om dig och andra som driver på med "Spaced Based Architecture". Verksamheten är oerhört viktig, jag har aldrig påstått något annat Jag säger inte heller att verksamheten måste lära sig arbeta process-orienterat, jag säger heller inte att mjukvara inte måste hantera processer. Däremot vet jag av erfarenhet, och branschen har smärtsamt fått erfara, att verksamheten inte förstår mjukvara och har inget intresse av att bli duktiga på mjukvara eftersom det inte ligger i deras "core-bussiness".

Om man tar en analogi med byggbrasnchen: Även om du idag kan rita ditt eget hus, så krävs det att en riktig arkitekt tittar på det och korrigerar vad du gjort så att det verkligen går att bygga och de allra flesta försöker inte ens rita sitt hus. De talar om vad de vill ha och ngn som förstår husbyggandet gör det åt dem.

På 80-talet var det väldigt många "ekonomi-chefer" som skrev mjukvara, det gick som det gick och grunden till många av de strukturer som finns idag kom som en reaktion på de programvaror som växte fram under den tiden när verksamheten fick härja fritt, när mjukvara fick byggdes top-down (gärna baserat på en "skärmbild"). Det är lustigt hur fort man glömmer den mardröm de systemen slutade i.

"Gör vi?"
Ja, disskusionen har handlat om hurvida man skall använda OO i sina .NET applikationer eller inte. DDD, bla, är ett verktyg för att vara så effektiv som möjligt med .NET, Java och andra objekt-orienterade plattformar.

"Olika verktyg har olika syfte, precis som med DSL'er. "
Absolut, visst är det så har allt olika syfte. Men den här tråden handlar inte om det.

"För .NET-utvecklare kommer WF spela en stor roll framöver och BPM har prognoser på 3 miljarder dollar nästa år."
Absolut, WF är stort. Jag har kört en mängd WF kurser och varit mentor i ett par projekt där WF använts. I inget av projekten, eller de scenarion som Microsoft målat upp för WF, har WF varit den dominerande delen av tiden man fått lägga ner på projektet utan WF har fungerat som "klistret" för att bygga samman mjukvarans olika delar, eller skapa flöden för specifika scenarion som uppstått, varken mer eller mindre.

"Det är enligt utvecklare att ha kontroll över läget. Den sista kommuniststaten skulle vissa ha sagt … "
Nej, det handlar om att du vill lösa de problem du har framför dig med de verktyg som du kan och arbetar med dagligen. Du vill inte som utvecklare vara tvungen att lära dig en ny plattform för varje projekt, det vill inte verksamheten att du gör heller eftersom TCO skulle vara sky-high om varje projekt började med att du skulle lära dig något nytt. Det är lite problemet med adoption för DSLer, man behöver hitta DSLer som är enkla men ändå påminner om vad utvecklare redan kan, det blir lite moment 22. Eftersom utvecklare inte jobbar med DSLer och det inte finns ngn egentlig "DSL standard" så blir det heller ingen återanvändning av komptens.

Genom att lära sig generiska plattformar och använda ramverk som ökar abstraktionen för vissa uppgifter så får du så nära re-use av kunskap och kompetens som du kan komma. Re-use av kompetens är viktigt, dels för kvaliten av mjukvara men också för att kostanderna inte skall sticka iväg.

"Där nere gör den ingen nytta, lita på mej. För det första så syns den inte där och för det andra så har processen inget med domänmodellen att göra. Domänmodellen är plumbing i sammanhanget. "
Den gör en enorm nytta där, för den som måste använda den. Dvs utvecklaren som skall skapa och underhålla mjukvaran. Dessutom blandar du igen här, du pratar om processer och arktiektur, jag pratar om kod. Det är helt olika saker. Att du och andra SBA vill organisera mjukvaran i processer och vill ha verktyg för att beskriva dem, ändrar inte det faktum att majoriteten av alla system idag byggs på en objekt-orienterad plattform och därför behöver verktyg för att implementera processer och annat i kod på den plattformen. och nej jag litar inte på dig i den här frågan.


"Återigen så visar du på en dålig insikt i de krav på variation av lösningar som verkligheten ställer."
Nej Jonas, det visar att jag skrivit min beskärda del av system och mjukvara, det visar att jag vet hur svårt det är att med XPath och SQL beskriva komplexa affärsproblem. Inget av språken var designade för det utan båda två är skapta för hämta data från olika datastrukturer, inte för implementation av affärsprocesser.

Det är minst 7 år in i "process och tjänstevågen" nu, säkert längre, 7 år är en lång tid i mjukvarubranschen. Trots det saknar vi verktyg av den typ du pratar om med en mognadsgrad som kan göra att det går att räkna med en bred genomslagskraft inom den närmaste tidsrymden.


Med den kommentaren, tillsammans med:
"så representerar du i ditt resonemang en grottmänniska"
och
"Ett tips till dej är att släppa sargen och åka ut på isen"

Så tycker jag att du visar på att dina argument börjar ta slut, det är enda anledningen jag kan se till att du slutat vara saklig och börjat med personangrepp.

Jag anser den här disskusionen avslutad från nu.

When the goings get tough, the tough goes!

Jag sänkte bara nivån efter att du i inlägget innan hade langat iväg ett antal av dina patenterade tåklamp som "Nu pratar du igen om äpplen och päron" och "hoppas jag du skämtar". Ursäkta men det jag skrev är bara uttryck och helt utan personlig anknytning. Jag vet att du inte bor i grotta ... eller?

Agila metoder verkar vi ju vara överens om, dvs att två världar inte kan kommunicera och därför väljer den ena sidan att börja koda istället.

Arkitekter i byggbranschen Patrik, det är inte de som kan byggnormer osv och plockar ner ritningarna på jorden. Det är arkitekterna som ritar husen och det är ingenjörer som plockar ned arkitekterna på jorden. Men jag förstår vad du vill säga och jag påstår inte att utvecklarna kommer att ersättas med slipsprydda affärsmän som drag-and-droppar aktiviteter i ett process-schema. Jag säger att processmodellen kommer att ersätta domänmodell (även om vissa prominenta herrar myntat namnet så har innebörden funnits länge ... alldeles för länge). Jag säger också att processmodellen implementeras lämpligast av en eller flera nivåer av abstraktion från C#. Det betyder inte att någon annan än utvecklare ska göra jobbet, det innebär att utvecklaren arbetar med rätt verktyg.

"I inget av projekten, eller de scenarion som Microsoft målat upp för WF, har WF varit den dominerande delen av tiden man fått lägga ner på projektet utan WF har fungerat som "klistret" för att bygga samman mjukvarans olika delar, eller skapa flöden för specifika scenarion som uppstått, varken mer eller mindre"

I ena andetaget citerar du MS och i det andra förkastar du dom. WF har prickat väldigt rätt och kommer att påverka mjukvaruutvecklingen mer än vad du verkar ge uttryck för. När du säger den dominerade delen så vet jag inte om du avser tid, kodrader, etc, men du har rätt i att det är ett "klister" och att det i rätt sammanhang driver utvecklingen av andra artifakter. Det betyder inte att bulkprogrammeringen ligger där och anledningen till att det inte är så är att det just är en annan abstraktionsnivå som du refererade till som 4GL.

"Nej, det handlar om att du vill lösa de problem du har framför dig med de verktyg som du kan och arbetar med dagligen. Du vill inte som utvecklare vara tvungen att lära dig en ny plattform för varje projekt, det vill inte verksamheten att du gör heller eftersom TCO skulle vara sky-high om varje projekt började med att du skulle lära dig något nytt."

TCO handlar inte bara om utvecklingskostnaden, det är en försvinnande liten del i sammanhanget. Kostnaden ligger i att systemen inte kan förändras med tiden och att man utvecklat system så komplicerat att man inte vågar ändra på det. De applikationer man bygger på det sättet du hyllar skapar dessa system.

"Att du och andra SBA vill organisera mjukvaran i processer och vill ha verktyg för att beskriva dem, ändrar inte det faktum att majoriteten av alla system idag byggs på en objekt-orienterad plattform och därför behöver verktyg för att implementera processer och annat i kod på den plattformen."

Anledningen till att jag överhuvudtaget sitter här och skriver är inte för att munkäftas med dig. Utan det gör jag för att ta på mej ansvaret att försvara förnuftet. När jag ser att 90-tals idéer försöker få fotfäste i forum av det här slaget där framtidens utvecklare formas så kan jag inte hålla tillbaka.

"Inget av språken var designade för det utan båda två är skapta för hämta data från olika datastrukturer, inte för implementation av affärsprocesser."

Visst är det så, men varifrån fick du att det skulle varit min åsikt? Affärsprocesser kan beskrivas på många sätt (BPEL, XAML, XLANG, BPMN), men C# är inte ett av dom lämpligaste sätten.

"Det är minst 7 år in i "process och tjänstevågen" nu, säkert längre, 7 år är en lång tid i mjukvarubranschen"

Du räknar hundår nu Patrik, eller försöker du med den vanliga att du har 100 års erfarenhet av branschen nu igen? Det händer mycket inom SOA/BPM och det händer snabbt. Det kommer du också bli varse om du vill jobba vidare med utveckling av programvara.

Det har varit en lärorik tråd och hoppas den uppskattades av fler än mej. Tyvärr så var det inte ett direkt svar på den ursprungliga frågan men jag tror vi slog rekord i antal inlägg i en tråd. Hoppas du inte tar det så personligt i fortsättningen Patrik, för så var det inte menat.

Tack,
Jonas Ekström
Microsoft

Jag säger att Patrik har vunnit på knockout..

Tråden skapades för att Sofia ville lära sig använda/designa OO för .NET

Patrik har varit hjälpsam berättat om OO.
Jonas har inte bidragit med någon info alls till Sofia och gled mer o mer till det provokativa hållet i slutet av tråden.

1-0 till Patrik.

---

Till Jonas:

Du jobbar ju själv på ett företag som utvecklar OO språk, Utvecklingsmiljöer för OO språk , ORMappers (dlink,entityframework).

Anser du att dessa projekt är felsatsningar?

Är de som tagit initiativen till dessa projekt är mindre begåvade än de som förespråkar andra sätt att utveckla?

*tar på mig provokatör hatten*

Roger,

Jag har inte befogenhet att uttala mej om de produkternas framtid. Jag har heller inte påstått att varken de som jobbar med dom produkterna du nämner eller de jag diskuterat med här är mindre begåvade. Det enda jag kan uttala mej om just nu är att det minst begåvad inlägget i den här tråden kom från dej!

btw Sofia frågade efter en bra design, inte en oo-design så det borde vara hon som avgör vad som hjälpte henne...

Det är helt OK att du tycker det.

>>Jag har heller inte påstått att varken de som jobbar med dom produkterna du nämner eller de jag diskuterat med här är mindre begåvade

Det gör du ju indirekt genom att idiotförklara de tekniker de utvecklar.

Tycker att det är lite fegt iaf att du inte vågar svara.
Du förklarar hur dåligt ORM är, men vågar inte säga vad du tycker om er egen ORMapper.

Och med min låga begåvning så tänker jag dra slutsatsen att om du tycker ORM är fel, så tycker du även de som utvecklar ORM är fel ute, även de som jobbar på samma företag som dig..

Annars är du välkommen att förklara var i mitt resonemenag det blev tokigt..

----
>>btw Sofia frågade efter en bra design, inte en oo-design så det borde vara hon som avgör vad som hjälpte henne...

*host* topic: "Sv: Objektorienterad design"