Posts

Showing posts with the label DDD

Onion architecture

Jeff seems to have put it very well in his blog. Much better than I did myself back in December 2006 when I blogged about my "Onion" idea. My mistakes were 01: I was missing a domain services layer. 02: I tried to explain it using a specific example (wizard app with a "process stack" aka "task stack"), and later decided I didn't like the example :-) 03: When I drew my diagrams I showed them as a typical stacked diagram, because my graphics skills are crap :-) Here's my badly put idea of onion layered applications: http://mrpmorris.blogspot.com/2006/12/net-onion-part-1.html Here's Jeffrey's http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ Well done Jeff, very nicely put!

Data Transfer Objects

My observations on data transfer objects They should not be a one to one representation of your domain classes. Sometimes you want a subset of the information of a single instance, sometimes your DTO will collect data from various instances (starting with an aggregate root ). You might create different types of DTO from the same domain classes based on what the user needs to do. Sometimes the user only wants OrderNumber + DateRaised + TotalValue (to show as a list of orders), sometimes they want the entire order details (including lines) for editing. The domain classes should have no knowledge of your DTO classes. So you shouldn't have any methods such as pubic PersonDto CreateDto(); public UpdateFromDto(personDto); DTO's are not part of the business domain, so you should never do this! The DTO you send out might not be the same type as you get back. For example you don't want the user to edit the order number or the date raised. If there are only a couple of properties...

Domain Driven Design by Eric Evans - my book review

To me this book has been a huge disappointment. Someone told me "Pete, there's a name for what you do!" and pointed me to this book. Now personally I prefer technical books, as I read the Ubiquitous Language part at the start I thought to myself "Not technical, but fair enough some people will get value from being taught how to ask questions" and I stuck with it. The first thing I must say that I cannot stand and which happens a lot in this book is over emphasis. When you want to emphasise something it needs to stand out. This book not only emphasises whole paragraphs but does it far too often too. Being an Internet user for some time now when I read upper case letters the imagined vocalisation actually SHOUTS at me, when I read bold my brain vocalises it as a loud and punctuated word, so when I read a whole paragraph in bold I, READ, EACH, WORD, LIKE, THIS ; it makes it difficult to read. Another thing I don't like when reading something is reading i...

Domain driven design, Test driven design

I was just reading through the VBUG events list when I came across an event entitled "Domain driven design approach, using unit testing". "Sounds interesting!" I thought to myself, I hope I can make it! As I started to read it I thought it looked familiar. At that point I realised it was me doing the talk! So hopefully I will be able to make it :-) The posting is here . If you come along make sure you say "Hello".