* Ex. klass som symboliserar ex objectet. Customer i mitt fall som jag använder som databärare, kan denna hänvisas till att vara ett Value object? * Ex. klass som symboliserar ex objectet. Customer i mitt fall som jag använder som databärare, kan denna hänvisas till att vara ett Value object? Instämmer helt med Johan! Om du vill ha lite mer info om hur du kan dela upp din lösning så kan du kolla på Jeff Palermos beskrivning den sk. "onion architecture" ( inget nytt enligt de flesta med det är rätt pedagogiskt beskrivet) Glömde att nämna att Jimmy Nilssons DDD bok är en "must read" om man vill lära sig DDD. Vilket supersvar! :) Vill inte kritisera Jimmys bok då jag själv var med och reviewa den, men jag tycker inte hans bok är den man skall läsa först för att förstå DDD, hans bok är ett superb komplement efter man läst Eric Evans DDD bok. Jimmy beskriver mkt kod, verktyg m.m. för att bygga bra DDD applikationer medans Evans bok är ren teoretisk bok om DDD, alla dess beståndsdelar, hur team skall/kan arbeta m.m. Då är de två köpen att överväga. Surfade runt lite grann på nätet och hittade en iten blogg med en kille som heter Bill Simser. Som visar kort en implementation av DDD typ i C#: Konstig kod. Nu börjar soppan bli lite klarare (tror jag) .. Har jag entiteten Customer, så kan ett value object vara kanske CustomerType och Name. Har jag entiteten Order, så kanske ett value object kan vara Ja typ så :-)Hur ni tolka mitt upplägg, som i närheten av DDD eller?
Value Objects: An object that has no conceptual identity. These objects describe a characteristic of a thing.
* Ex. klass som ex kallas för CustomerData, innehåller metoder för att hämta "data" från ex. en databas och sedan fyller min databärare för vidare transport uppåt.
Repository: methods for retrieving domain objects should delegate to a specialised 'repository' object such that alternative implementations may be easily interchanged.
* CustomerData innehåller också metoder för att spara ned värdena från en ned skickad databärare till databasen ex.
Factory: methods for creating domain objects should delegate to a specialised 'factory' object such that alternative implementations may be easily interchanged.
* Kan min CustomerData ses som en blandning mellan en Repository och Factory? Och för att komma närmare DDD, dela upp mitt CustomerData i CustomerRepository och CustomerFactory?
* Om jag ex har en klass som jag kallar för Helper, och i den har jag ex. metoder för hashing, encrypting, decrypting ósv. Kan min Helper-klass ses som Services då?
Service: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services. The Service concept is called "Pure Fabrication" in GRASP.
Är ingen expert på DDD eller så, utan bara läst lite grann på nätet här och där. Sv: Hur ni tolka mitt upplägg, som i närheten av DDD eller?
Troligen kommer din Customer ha en identitet ex ID i db eller nått så du kan leta upp denna på så vis blir det inte ett value objekct utan en ren entitet i DDD.
Price skulle ex kunna vara ett value objekt. Det har ingen identitet utan innehåller bara ett värde som är pris för ex en vara. Customer kan dock om man skall röra till det kunna vara ett value objekt om det inte har en identitet. Se value objects så som du ser på Int, Double... value objects i DDD skall leva som dessa lever typ.
Ex om din Customer skulle vara ett value objekt så när du hämtar två Customer med samma adress så skall de vara två kopior utan identitet… Kanske lite luddigt förklarat. Tror det är väldigt ovanligt att en Customer kan vara ett value objekt i ett system då det oftast alltid rör sig om en kund o den har faktiskt en identitet.
* Ex. klass som ex kallas för CustomerData, innehåller metoder för att hämta "data" från ex. en databas och sedan fyller min databärare för vidare transport uppåt.
Alla klasser som hanterar dina entiteter mot datalager/datakälla bör heta <AggregatRoot>Repository.
Dvs AggregatRoot är bärande Entiet. Typ CustomerRepository (OBS! då är inte din Customer ett value objekt). Value objects har inga egna repositories.
CustomerData skulle kunna vara en factory, men frågan är bara då vad skapar den?
Jag skulle nog då döpt den till CustomerFactory för att enklare gruppera in i namn vad mina komponenter har för uppgift. Blir lätt att man skapar massa objekt med olika namn och av namnet inte direkt kan avgöra dess funktion.
Normalt använder jag factories till att skapa mina repositories i de lägen de behöver lite mer kod för skapas och då använder jag även Di/IoC ramverk. Lite mkt info på en gång kanske.
Kort o gott: Dina Repositories skall använda olika datakällor och du vill kanske enkelt byta ut dem, då kan det hända att du gör en konstruktor som tar emot ett interface, IDataSourceHandler eller nått (tog bara ett namn nu)... För att slippa skriva;
var customerRepository = new CustomerRepository( <kod för att skapa IDataSourceHandler> )
Så kan man ha RepositoryFactory med ex metoden CreateCurstomerRepository() och i denna använder man ett DI/IoC ramverk för att dynamiskt skapa det objekt man vill ha in i konstruktorn, detta styr man exempelvis via XML fil. Se MS ObjectBuilder eller Spring .net för mer info.
I sådana lägen är Factories guld värda. Dvs använd Factories då det det blir för mkt kod för att skapa ett objekt själv.
* Om jag ex har en klass som jag kallar för Helper, och i den har jag ex. metoder för hashing, encrypting, decrypting ósv. Kan min Helper-klass ses som Services då?
Detta ser jag mer som klasser som hör hemma i Infrastructurlager. Dvs hör inte till Domänen alls utan aggerar hjälpmedel för vissa Service/Factory klasser eller liknande...
En Service klass brukar jag oftast förklara som ett objekt som gör saker åt mina entiteter men detta objekt i sig har ingen egen identitet. ex TankStation som skall tanka din bil. tankstation är bara en tjänst för tankning. Då min bil inte kan tanka själv. En del avancerad businesslogik kan även ligga i Servcie klasser. Ex spara en order som skall uppdatera status m.m m.m. under en transaktion etc...
Servcieklasser får använda andra klasser så som factories, repositories för att utföra sitt jobb mot dina entiteter/valueobjects.
Så det är i princip hjäplklasser för dina domänobjekt medans andra hjälpklasser som inte kräver vetskap om din domän är infrastrukturklasser.
Det är inte lätt att förklara DDD i text etc... I många lägen är det lättast att rita upp domän problematiken och rama in vad som är vad beroende på vad ditt system skall göra m.m. via white board eller liknande. Men jag hoppas detta gör det lite tydligare.
Mvh JohanSv: Hur ni tolka mitt upplägg, som i närheten av DDD eller?
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/Sv: Hur ni tolka mitt upplägg, som i närheten av DDD eller?
http://www.amazon.com/exec/obidos/ASIN/0321268202Sv:Hur ni tolka mitt upplägg, som i närheten av DDD eller?
Man tackar så jättemycket.. då är jag mer förstående i det hela. Sv:Hur ni tolka mitt upplägg, som i närheten av DDD eller?
Så Evans först sen Jimmys... Brukar jag rekommendera.
Dock kan det ibland faktiskt vara så att en teknisk bok som Jimmys är bäst att läsa först för att ändra sitt tankesätt från kod till design, för att sen läsa Evans för att få ännu mer hum om vad man egentligen kodar. Men detta är två olika inlärningssätt.. Hur man lär som person.
Båda böckerna är kanon på sina sätt... Och som sagt bra komplement till varandra så köp bägge :) A most have i hyllan även om man kanske inte kommer gilla DDD :-)
Mvh JohanSv: Hur ni tolka mitt upplägg, som i närheten av DDD eller?
namespace Car
{
class Wheel { ... } // entity
class Position { ... } // value object
class CarRepository { ... } // repository
class FuelTransfer { ... } // service
}
Om jag nu tolkar koden ovan.. skulle man kunna säga att namespace = domain, och rest är ju då klart. :)
Som sagt var så oavsett vilken bok jag läser om olika designmönster som ex DDD så är det alltid så förbenat svårt att omsätt sakerna i ren kod.
Skall titta in på de där två böckerna.
Sv:Hur ni tolka mitt upplägg, som i närheten av DDD eller?
Namespacet skall typ vara modulen. I detta fall har han en klass namn som namespace.
Sen har han en Repository för Car men ingen Car klass...
Wheel i hans fall kan mkt väl vara value object, samma med Position, men både Position ochn Wheel kan även vara enties. Så det går faktiskt inte med kod bara säga detta är det ena o detta är det andra, då det handlar helt och hållet om hur de lever i din domän.
Mvh JohanSv:Hur ni tolka mitt upplägg, som i närheten av DDD eller?
ex OrderType.
Att dessa value objects inte har en konceptuell identitet, utan att de snarare beskriver karaktären på en något. Sv: Hur ni tolka mitt upplägg, som i närheten av DDD eller?
Det är objekt som är namn för din domän modell och det språk ni för.
Ex säger man sen vill jag att Price skall skickas till Transaktion A så är ens Price ett value objekt, dvs en klass med namn Prive o en property som kanske heter value eller nått. För har man prop Price som int på en Order så blir det egentligen int man pratar om o inte Price sen om Price intärnt använder int eller double eller nåt som value är en annan sak.
Så man översättar alltså affärsorden till objekt av de olika karaktärer de är. På så sätt kan det bli en hel del value Objects.
DoFoo(Price price) säger mer än DoFoo(double price) Här är det typen double och inte price... Du skickar alltså runt en double i exempel två som kan vara vad som helst, medans value objektet Price alltid är price.
Mvh Johan