Har läst en del om DDD och tittat på olika exempel men har lite svårt att få rätt på vad jag vill.

Säg att jag bygger en serviceklass som har en klass Customer, på denna klass skall man kunna göra lite affärslogik, för enkelthetens skulle så skall man bara kunna göra IsValid() HasOrder(). Det finns även lite data på Customer, så som ID, Namn.

Min serivcesklass skall kunna ta emot en Customer och spara den till något ställe, säg databas. Den skall även kunna hämta Customer och skicka från servicen.

Så min fråga är jag skapar ett Entity-object som heter Customer i min domainmodel. På detta objekt så skapar jag 2 metoder, IsValid() och HasOrder() och sköter logiken där i. Jag har dessutom 2 properties på detta objekt: ID och Namn.

När jag sedan vill skicka iväg min "CustomerEntity" från servicen, så har jag ett DTO-objekt som bara består av 2 properties: ID och namn, som jag fyller med data och skickar iväg detta.

Har jag förstått det rätt så fall? För jag har sett exempel med Entiteter utan logik och manager klasser som opererar på dessa entiteter där man har kallat designen för DDD. Vilket är lite förvirrande...

Själv så tycker jag det blir jobbigt med alla DTO objekt som skall mappas fram och tillbaka, vad tycker ni om att skicka iväg "det riktiga Customer entiteten" från services. Alla metoder kommer ju strippas bort och bara properties markerade med [DataMember] kommer skickas. Är ju rätt skönt att slippa allt mappande, men "hur fel" är det att göra så?

- M

Tror du fått det lite fel här :/

DTOer är etn lösning om du måste skicka lätta objekt över olika kommunikationssätt. Dvs säg från Backend till handdator. Från backend via Webservices eller liknande. DTO er är Transfer objects inget annat.

Så i din domän skall du fortfarande använda din Customer klass, och den skall inte ha någon koppling till DB eller nått sånt, den kod som ligger i dem skall helst bara orientera sig inom sina state och ev subklassser i staten. Annan tyngre logik bör ligga i ex Service klasser.

IsValid() förstår jag inte alls vad den gör. Bättre namn på den kanske? ;)
Har din Customer en association till Order? med tanke på din HasOrder? Där du då kollar en prop på Customer som typ heter Order? Jag skulle nog inte gjort så utan haft en OrderService som kan kolla detta år mig.

orderService.HasCustomerOrder(customer,order);

Eller så skulle jag kolla om min order har en customer där det känns som customer bör ligga.

class Order
...
public bool HasCustomer(customer)
{
customer.DontAllowNull("customer");

return(_customer.Equals(customer));
}

Eller det motsatta om din Customer har associationer till Order.

ID och Namn skulle jag behålla... Lika så businesslogiken och inte haft DTOer om jag inte skall transportera dem mellan olika klienter eller sevrar.

Mvh johan

- Jag skall skicka iväg mina customer objekt från min services till en applikation, frågan är om jag "måste" ha DTO eller kan skicka iväg mina business objekt direkt.

- IsValid() och HasOrder() är bara exempel funktioner, för att visa på att det finns logik i entityn, så frågan var om business objekten skall ha både data och logik. Eftersom jag sett exempel där man använt sig av "Manager" klasser och skickat in entity till dessa och kallat detta för DDD.

En annan fråga är om jag använder mig av DTO, är det a big no no att wrappa dessa i sina business entiteter så man slipper mappa så mycket fram och tillbaka, utan mer kunna plocka ut dessa direkt.

public class Customer{

private DTOCustomer _DTOCustomer;

public string Name{
get{reutrn _DTOCustomer.Name;}
set{_DTOCustomer.Name = value;}
}
}

Är det en riktigt fuling, eller något som man kan accepter i en DDD design.

- M

Ja de där manger o halder patternet alltså :-) DDD är egentligen inte bara en lösning utan hur man tänker för att ta fram sin domän. Så det vi pratar om är mer DM (Domän model) i DDD typ...
Men Mangers o Handlers hör inte till klassisk DDD... Det är en annan approch.

Entiteter skall ha businesslogik i sig men de skall helst handla om att hantera deras sates info inget annat. Dvs de skall inte nyttja Serviceklasser eller Repositories i sig (så vida man inte kör med lazy load. men det är ett annat topic).

DTO används som sagt för att minimera storleken och ha dem för transport. Men så länge du kör en webbapp, eller winform app behöver du inte använda dem utan kan nyttja dina Entiteter precis som du vill. har du business metoder på dem som du inte vill att UIt skall se, använd då Interface istället för DTO det är mitt tips.

http://martinfowler.com/eaaCatalog/dataTransferObject.html
http://msdn.microsoft.com/en-us/library/ms978717.aspx

Okej.

Så mina entiter = business objekt hamlar i DomainModel "lagret". Och dessa innehåller både data och logik för att hantera detta objektets tillstånd.

Persistering och "logik över fler klasser" hamlar i DomainServices "lagret" eller i ApplikationServices "lagret" (om man tittar på Onion Arcitechtur.

Från min services så skickar jag ett DTO som jag mappar mot mina entiteter. I min applikation så kan jag använda mig av interface för att gömma logiken från UI som den inte skall se.

Då har jag egentligen bara en fundering. Om UI kräver extra information som inte har med min entiteter att göra, skapar man speciella UI-DTO då eller kan man lägga till denna information till interfacet och på bara göra dessa synliga genom det interfacet.

Jag har en klass som heter Category och den skall binda till en TreeView (WPF) och för att få det att fungera som jag vill, så behöver den 2 extra properties: IsExpanden och IsSelected. Dessa har ju absolut inget alls med mina business entiteter att göra, utan borde ju bara finnas i UI. Innan så har jag skapat specifika TreeViewItems som har en instans av en DTO, och där med inte kladdat ner mina business entiter, men det tar bort möjligheten att binda direkt från XAML, och kräver att jag kodar mig runt detta i code-behind klassen, vilket jag inte tycker är så snyggt...

Men om man håller dessa till Interfacet för UI så borde det ju ändå bli ganska snyggt, plus att man slipper mappa runt som en galning.

Undra om man kan skicka ett interface från en services med WCF, har inte testat men det känns inte som det skulle fungera, men så fall hade man ju sluppit DTO:erna och livet skulle vara underbart.

- M

Men du behöver inte DTOer alls som det verkar.

Ja de där propparna du pratar om för treeview är väl inte så kul. Jag skulle nog wrappa om min Cateogry till en typ UICategory för treeviewn för att slippa dessa proppar helt i mitt domänlager då de inte hör hemma där.

DTOer kan du glömma, tänk inte ens på dem du behöver dem inte. Så länge du inte måste transportera objekt mellan olika protokoll så som soap...

Tänk på att det är Entitetsaggregat rootens Repository som hanterar persistens inte service klasserna. Dock kan serviceklasserna använda sig av Repositories.

Mvh Johan

För att svara på din fråga om wrappningen så tycker jag det är en klockren lösning istället för mappning.

Jag har en fråga angåend användandet av Repsoitory.

Jag har sett 2 varianter här, där man gör följande (förenklat)

DomainServices -> Repository_REAL -> GetDataFromStorage
DomainServices -> Repository_TEST -> CreatedTestData

eller

DomainServices -> Repository -> DataAccess_REAL -> GetDataFromStorage
DomainServices -> Repository -> DataAccess_TEST -> CreatedTestData

Så det jag undrar är egentligen vem som ansvara för att rätt data kommer fram, är det repositoryn, som användersig av olika "DAL" för att få rätt data.

eller är det DomainServices som använder sig av olika repository för att få fram rätt data.

2 känns lite mer korrekt att det är repositioryt som ansvara för att rätt data kommer fram, men samtidigt så blir det iprincip bara extra lager.

- M

Det är respos ansvar att se till så rätt data kommer o sparas...
men servcie som kan ha ex transaktionshantering i sig...

Det beror helt och hållet på vad det är du testar.

Om du skall testa domainservice i isolation, då mockar du repositoryn. Om du skall testa repositoryn i isolation så mockar du data access.

Jag testar f-ö sällan repository i isolation, det ger mig inget mervärde. Skrev en post om det där:

http://www.lowendahl.net/showShout.aspx?id=204

Okej, jag komplicerade det nog en del. Vad jag egentligen vill veta var.

Om jag använder en O/RMapper, skall koden för att hämta data ligga i repositoryt eller skall repositoryt kalla på ett DataAccessLayer som i sin tur anropar O/RMappern.

- M

Jag lägger det i repository, enda anledningen till att ha ett separat DAL är om du vill kunna byta data access strategi, tex mellan NHibernate och lokala filer eller liknande.

Tänk K.I.S.S, skapa inte lager bara för att, utan var noga med att varje lager verkligen har ett direkt syfte i din kod.

"Jag lägger det i repository, enda anledningen till att ha ett separat DAL är om du vill kunna byta data access strategi,"

Tja det är ju inte värre än att jag bygger ett nytt repository så fall, det är ju baserat på ett Interface. Det känns mer rätt att ha ett DAL, men samtidigt så kommer ju repositoryt så fall bara bli en wrapper runt DAL:et och det känns ju onödigt precis som du säger.

- M

Se ORM ramverket, eller ADO.Net eller vad du använder som ditt DA istället...

Glöm typ MS nTier med BL o DAL. Det finns inte på samma sätt i DDD.
Repositoryn är typ det som nästan motsvarar DAL klasser... Rätt onödigt att nyttja Repos lite som en fasad mot ytterliggare ett lager precis som Patrik säger.


http://www.swenug.com/files/folders/goteborg/entry37.aspx

Här kan du ladda ner en PPT som mer eller mindre täcker Domän Driven Modell. Den tar dock inte upp tänkandet m.m. men de delar som ingår i DDDs modell...