-
Continuing our series on Domain Driven Design, we now get to one of the more interesting patterns in DDD – the Specification . A Specification is, in simple terms, a small piece of logic that sits on it’s own and gives an answer to a simple question … “does this match?” With a Specification we split...
-
It is funny how often I find this problem, one I like to categorize as: All users lie Now that statement, especially in isolation, rarely garners me any friends, and tends to put people’s backs up. But please don’t hit me and read on first. House MD My girlfriend’s favourite series of the moment is House...
-
The series of posts here was starting to get rather frantic, and I realised that I was swamping devlicio.us and all the other bloggers, and that the comments and discussions were becoming fragmented across multiple blog posts. So I figured I would pause, reconsolidate, and do this series in a way that...
-
No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune putting SOA around. Domain Driven Design appears to be at odds with large scale distributed systems, it is after all methodology to design and write application software, and in SOA we don’t...
-
I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we get to the last major part of the Domain Driven Design picture – Repository . In traditional architectures, your application talks to some kind of database layer, and asks it to save or retrieve your...
-
In many conversations, and in many comments here, you hear phrases like “well that’s not really suited to DDD” or “DDD isn’t the best fit for that problem”. You even see those kind of comments on my blog, and often they are posted by me. This obviously leaves a number of people confused, after all DDD...
-
There can be no word more common in development, and no word used for such a multitude of different things as “service” It was therefore unfortunate that Eric Evans introduced yet another concept of Service in DDD, one which has since been referred to by some as a Domain Service . However, people often...
-
Download the eBook of the Series so far … We are family I got all my sisters with me Sister Sledge Some things belong together, like Apple Pie and Ice Cream, or Sonny and Cher. And so it is with Entities and Value Objects (VOs) – some of them belong together. Aggregates are groups of things that belong...
-
To save you lots of clicking backwards and forwards as each part of this series on Domain Driven Design appears, I am going to collate the posts along the way into a downloadable PDF format. The parts so far can be downloaded from here UPDATE: This link has now been changed to the new URL the elements...
-
Right about now I can hear murmurs, "I haven't seen any code yet" That is because I view Domain Driven Design firstly as a design methodology, secondly as an architectural style, and lastly as some great software patterns. I don't believe I am alone in that view, after all it is a significant...
-
Finally, after 5 posts in the series, we get to the beginning point, the basis of all things… Entities and Value Objects . OK, maybe a small exaggeration, but Entities and Value Objects (VO) form the core building blocks of Domain Driven applications. Why has it taken this long to get to something so...
-
There has been some confusion recently around a recent evolution of DDD, the idea of Command Query Separation (CQS) at the architectural level. This post is yet again jumping ahead into the “advanced” stuff, so go ahead and skip this if you just want to get the basics down first… those will come soon...
-
Do not try to bend the spoon; that's impossible. Instead only try to realize the truth: There is no spoon. The Matrix Again prompted by discussion on the DDD Yahoo list, this post is intended to explain what on the face of it is a pretty dumb assertion – there is no database in DDD! I’m sure right...
-
It was brought up indirectly in a comment on my last post … the idea of a Ubiquitous Language (UL) seems like it is too all encompassing. Indeed it is – unless you are working on a very simple application, one language just isn’t enough. Not only that, but a single “mammoth model” will also be too large...
-
I'd like to buy an argument. I'm a proponent of isolating application tiers via separate physical assemblies; e.g., MyProject.Core for domain objects and logic vs. MyProject.Web for views. While I do not encounter much push back with this idea, I seem to raise eyebrows with my desire to move...