Om te oefenen met Domain Driven Design (DDD) en mijn kennis over het Windows Azure Platform te vergroten heb ik als hobby project het bouwen van een e-commerce applicatie (webshop).
Het Object Model bouw ik stap voor stap op, gescheiden Aggregates (Orders / Voorrraadbeheer / etc.), en probeer ik op zoveel mogelijk 1 op 1 terug te laten komen in de code.
(Al zitten hier wel wat implementatie verschillen in, denk aan abstracte klasses e.d. Ik vond dat dit teveel 'vaagheid' in het domain model gaf op papier, waardoor het slechter te begrijpen zou zijn door 'domain experts'. Klopt dit?)
Nu wil ik de Windows Azure Table Storage gebruiken om het geheel op te slaan, en dat brengt nogal wat technische 'beperkingen' met zich mee. Bijvoorbeeld: Een lijst met orders aan een klant hangen, en gelijk persistenten gaat niet lukken. Dit wordt door de Azure client niet geserialized, en dus ook niet opgeslagen.
Volgens mij is het Object Model sterk relationeel (Klant -> Orders -> OrderRegel etc.), dus de keus voor Windows Azure Table Storage zou ook zo een slechte keus kunnen zijn. Maar het lijkt mij sterk dat je DDD en NoSQL niet met elkaar kan verenigen zonder een enorme 'technical debt' te veroorzaken.
Tot zover de context, mocht er behoefte zijn aan meer dan hoor ik dat graag
.
Nu zou ik mijn Object Model natuurlijk kunnen aanpassen om rekening te houden met, bijvoorbeeld Partition en Row Keys, en de andere technische beperkingen van Azure Table Storage. Maar dit druist in tegen het principe van 'persistence ignorance' van je Object Model. Dit kan natuurlijk zo opgelost worden: http://blog.kloud.com.au/...namic-tableserviceentity/
Maar ik hou dan het probleem dat collections (bijv.) niet opgeslagen kunnen worden op een transparante manier, waardoor ik dus ook in mijn domain model zou moeten werken met functies op repositories.
Zoals:
En dit alleen om persistence goed te laten functioneren, dit lijkt mij niet wenselijk.
Een andere oplossing zou kunnen zijn om een vertaalslag te maken tussen je Object Model en je Data Model, maar hier ben ik bang dat het een enorme technical debt oplevert waardoor het refactoren van je Object Model een enorm dure bezigheid wordt. Dit omdat je naast het veranderen van je Object Model ook je Data Model + vertalingslogica moet gaan refactoren, wat de kans op bugs natuurlijk aanzienlijk vergroot.
Verder is er wel het een en ander te vinden op internet, maar de data modelling voorbeelden die ik vind op internet zijn meestal beperkt tot zeer simpele entities (alleen properties, geen collections of nesting).
Ik snap dat er enigszins beweging is tussen de technische implementatie en het domain model zodat ze elkaar niet uit het oog verliezen, maar volgens mij trek ik met Azure Tables dan het hele object georiënteerde om.
Iemand met een goed idee of ervaring hiermee?
Het Object Model bouw ik stap voor stap op, gescheiden Aggregates (Orders / Voorrraadbeheer / etc.), en probeer ik op zoveel mogelijk 1 op 1 terug te laten komen in de code.
(Al zitten hier wel wat implementatie verschillen in, denk aan abstracte klasses e.d. Ik vond dat dit teveel 'vaagheid' in het domain model gaf op papier, waardoor het slechter te begrijpen zou zijn door 'domain experts'. Klopt dit?)
Nu wil ik de Windows Azure Table Storage gebruiken om het geheel op te slaan, en dat brengt nogal wat technische 'beperkingen' met zich mee. Bijvoorbeeld: Een lijst met orders aan een klant hangen, en gelijk persistenten gaat niet lukken. Dit wordt door de Azure client niet geserialized, en dus ook niet opgeslagen.
Volgens mij is het Object Model sterk relationeel (Klant -> Orders -> OrderRegel etc.), dus de keus voor Windows Azure Table Storage zou ook zo een slechte keus kunnen zijn. Maar het lijkt mij sterk dat je DDD en NoSQL niet met elkaar kan verenigen zonder een enorme 'technical debt' te veroorzaken.
Tot zover de context, mocht er behoefte zijn aan meer dan hoor ik dat graag
.Nu zou ik mijn Object Model natuurlijk kunnen aanpassen om rekening te houden met, bijvoorbeeld Partition en Row Keys, en de andere technische beperkingen van Azure Table Storage. Maar dit druist in tegen het principe van 'persistence ignorance' van je Object Model. Dit kan natuurlijk zo opgelost worden: http://blog.kloud.com.au/...namic-tableserviceentity/
Maar ik hou dan het probleem dat collections (bijv.) niet opgeslagen kunnen worden op een transparante manier, waardoor ik dus ook in mijn domain model zou moeten werken met functies op repositories.
Zoals:
C#:
1
2
3
4
5
| // Orders van customer ophalen, ipv customer.Orders (of customer.GetOrders()) _repository.GetOrders(customerId); // Order toevoegen aan klant, ipv customer.Orders.Add(order) of customer.AddOrder(order). _repository.AddOrder(customer, order); |
En dit alleen om persistence goed te laten functioneren, dit lijkt mij niet wenselijk.
Een andere oplossing zou kunnen zijn om een vertaalslag te maken tussen je Object Model en je Data Model, maar hier ben ik bang dat het een enorme technical debt oplevert waardoor het refactoren van je Object Model een enorm dure bezigheid wordt. Dit omdat je naast het veranderen van je Object Model ook je Data Model + vertalingslogica moet gaan refactoren, wat de kans op bugs natuurlijk aanzienlijk vergroot.
Verder is er wel het een en ander te vinden op internet, maar de data modelling voorbeelden die ik vind op internet zijn meestal beperkt tot zeer simpele entities (alleen properties, geen collections of nesting).
Ik snap dat er enigszins beweging is tussen de technische implementatie en het domain model zodat ze elkaar niet uit het oog verliezen, maar volgens mij trek ik met Azure Tables dan het hele object georiënteerde om.
Iemand met een goed idee of ervaring hiermee?