DDD Step By Step
A Practical Guide to Domain Driven Design

February 2009 - DDD on the Web

Sort by: Most Recent | Most Viewed | Most Commented

  • DDD-Lite: Mama don't let your objects grow up to be invalid (take two) by John Nuechterlein

    So, in a previous post , I was making a point about preventing classes from being invalid by getting rid of setters (public setters at least). But, I did it in a way that was misleading, or at least could be. For one thing, I used the term ‘entities’ in the title of the post. Why was this bad? Well, within DDD, there is a distinction that is often made between objects that can be called “entities” and those that can be called '”value objects.” And the purposefully simplistic example that I used (that of an Address class) is normally considered to be a value object and so the title of the post seemed to be inaccurate. Moreover, it made it seem as if the general point really only applied to value objects, when in fact, it has as much, if not more, to do with entities. What is the distinction between an entity and a value object? Read the book . Thanks for coming, good night! No, no, that won’t do. Though there are different ways of laying out the distinction, one way of making it is to say that a value object can be defined in terms of the collection of its attributes, while an entity is something that has an identity over and above its attributes. The basic idea seems simple enough: if two Addresses have the same street address...
    Filed under: ,

  • Domain Driven Design Step By Step by Jérémie Chassaing

    Casey Charlton is moving his DDD series on a wiki site so that every body can put it’s personal touch. You can find it and participate at : http://dddstepbystep.com/ Expect me to write there ! Read More...

  • DDD - Not just about patterns by Yves Goeleven

    I have recently read Evans' literary master piece for the 4th time, and I now believe that I start to really understand all of the other gems hidden in the book.Most people think that Domain Driven Design is about patterns, but in reality the patterns are only a small piece of the guidance provided. I can see 4 big topics in the book which all cover different aspects of the development cycle, providing guidance to all roles within the development team. 1. On the one hand Evans discusses proven modelling techniques targeted to the development and maintenance of complex applications, a goldmine for program managers. 2. Furthermore it describes a lot of principles and best practices for supporting the development process, mostly targeted at the project manager and team lead. 3. Pragmatic strategies allowing applications to scale in size and complexity while maintaining integrity, which is a pretty big concern for IT management and enterprise architects. 4. And lastly it provides a set of patterns that support a clean and coherent view of the domain model, but you probably know this already. The first 3 of these topics do not get enough attention in the blogosphere, so I decided to dedicate a little of my time to these, starting tomorrow...

  • Who Knew Domain Validation Was So Hard? by Justin Etheredge

    I’ve been following intently the conversation that has been going around recently surrounding Domain Driven Design and validation within the domain . I have been swirling it around in my head for a bit,  and I’m still not quite sure that I am 100% in the game, but I wanted to get my thoughts out on paper (or at least on my blog) so that others would have a chance to respond. In case you have not been following it, the core of the discussion has been revolving around the appropriate place for validation to reside in your application. For many the result was surprising…it should never be in your entities. And interestingly enough, this conclusion seemed to be supported fairly universally by the people responding to this post. Nagging Fears While I guess this should be surprising for me, especially considering the fact that I recently helped design a system where there is a significant amount of validation within entities, I can’t honestly say that it did. The idea of having domain entities validate themselves never really set easy with me. But at the same time, I struggled a bit with the proposed solutions for it. I mean, I can completely understand how contextual validation is, but moving it out of the entities can leave the validation...
    Filed under:

  • DDD-Lite: Mama don't let your entities grow up to be invalid by John Nuechterlein

    Update: Troy pointed out that using Address as an example wasn't good, because in DDD, Address is considered what is called a 'value object' which has different features than what are called 'entities.' Since the point I was trying to make was about validation and why eliminating setters is an important concept, that wasn't totally relevant, but it's a valid objection (pun intended) as it could be misleading. So, I'm going to update the example. In a minute or two. Just keep that in mind till then. One of the hardest things about ‘continuous improvement’ (which I think really amounts to ‘not sucking more at the end of the day’, but I digress….seriously, some steps one might take to become a better developer are steps backwards, which I think the ‘craftsmen’-type people don’t discuss enough…but I digress) is trying to keep up with all of the possible information out there, from blogs, whitepapers, and other things. I estimate the number of posts I get in my various readers are dozens a day. Even filtering out the fluff, there is a lot of great stuff out there. On top of that, I subscribe to a number of mailing lists, which just increases the number of things to read on a daily basis if I want to keep...
    Filed under: ,

  • DDD: Step by Step Guide by Casey Charlton by John Nuechterlein

    Casey Charlton is putting together a series of posts about DDD that are downloadable in a single PDF file here . As he updates his series, he updates the PDF. I think this is a great service. It introduces a number of the most important concepts of DDD in a clear and concise way which helps to dispel a lot of the ‘DDD is mystical’ stuff. Even if the actual experience of practicing DDD has ‘mystical’ aspects (Casey knows I’m a bit skeptical about this, though I think I do get the point…to a point), many of the main concepts of DDD can be explained succinctly and his blog series proves it. I actually want to be able to apply some of what he explains to my ‘DDD-Lite’ ‘series’ of posts, which has been a bit meager recently (though that is because I’ve actually been applying some of what I had already mentioned). One point (about eliminating setters) I hope to post about soon. Regardless, check out his series. Great stuff. Read More...

  • Spiff Up Your ASP.NET MVC Forms With jQuery by Justin Etheredge

    Since many people who are being introduced to ASP.NET MVC are being simultaneously introduced to jQuery I felt like I’d give you a quick introduction to a few jQuery plug-ins that will help you make better forms. But most importantly make your forms better without you really having to do too much to them. What I am going to show you here is nothing new, but hopefully it will introduce a few people to the joys of jQuery plugins. The plugins that we are going to take a look at are jquery.blockUI, jquery.form, and jquery.datePicker. We are also going to introduce you to a good bit of standard jQuery. But first, let’s start off by talking about what each of these plug-ins will do for you. The blockUI plugin will give you that cool effect that overlays the UI with a modal dialog and fades out the background. The form plugin lets you post forms via javascript. The datePicker plugin does exactly what it says, it creates date pickers. The jQuery UI project has a date picker as well, but this is just a simple usable date picker. Our goal is to end up with a form that has watermarks: Row Highlighting: Hovering help messages: Ajax Submit with Modal Dialog:   And a date picker: First we are going to start off with a simple ASP...

  • Architecture Days in Spain by Udi Dahan

    The good folks from iMeta will be having me over in Spain to give my full-day SOA+DDD tutorial. Price looks pretty attractive too. Hope to see you there. Register here Read More...
    Filed under:

  • Entropy in software by Jimmy Bogard

    One of the greatest lessons I had growing up was from my music teacher, on improvement: You’re either getting better or getting worse, but you’re never standing still The same applies to a software system.  Any software system’s design either gets better or worse with each change made.  Often times, we borrow on our technical debt for a short-term gain, knowing we’ll need to repay the debt later with some larger refactorings.  This is a tactical choice made at the expense of a potentially strategic advantage. I believe that it is the natural order of software to gravitate towards a “ big ball of entropy ”.  It’s why I think velocities on teams level out over time – simply because it can become more and more costly to make changes to a system.  If we’re not proactive on eliminating duplication when we find it, that big ball of mud will be right around the corner. Once designs grow to a certain size, effort has to be made on the macro level to break apart concerns.  Separation of concerns on the class level can only take you so far, eventually you’ll need to take separation of concerns to the system level, and implement strategies like messaging/SOA to keep systems independent, decoupled and cohesive. ...
    Filed under:

  • Europe VAN - DDD with Greg Young (9th February) by Colin Jack

    The delayed first E-VAN is on now with Greg Young, discussing DDD and CQS. The URL is: http://snipr.com/virtualaltnet (Live Meeting). NOTE: This one was a success and Greg did a superb job explaining DDD and messaging, really enjoyable stuff. Read More...

  • P&P Guidance - Positive Progress by Colin Jack

    I put up a post a while back about the P&P REST guidance which I considered to be quite flawed. The reaction from the P&P team was superb and Greg Young , Sebastien Lambla and myself immediately got involved in an e-mail exchange with them regarding this and other guidance. They've shown they are incredibly open to feedback and we're still involved in this exchange but it looks like the result may be changes to the existing article and/or new articles. One thing I hadn't realized before this started is that P&P actually have three different sites: Guide – http://www.codeplex.com/AppArchGuide Knowledge Base – http://www.codeplex.com/AppArch Community Site – http://www.codeplex.com/AppArchContrib The community site is quite open so even if our examples use open source frameworks they can still be published on it. I'm therefore planning on writing one example using WCF, NHibernate and Castle where the two primary areas covered will be: REST - Although the current example says its using REST I think this is arguable. Domain Model - I'll be using DDD patterns but I've tried to explain that DDD isn't always appropriate (e.g. if you don't have access to domain experts). Regardless...

  • DDD Aggregate Component pattern in action by Jimmy Bogard

    In my last post, I went on a long-winded rant on how the composition and the Aggregate Component pattern can ease the burden of the interaction between Entities and Services.  The question comes up often on DDD or IoC forums: How do I inject/use a Service/Repository inside an Entity? You can get really fancy with your ORM or really fancy with your IoC Container to try and make your Entities join in an unholy matrimony.  But there are other, better ways of skinning this OO cat. The hard way We may try to get these services injected through our ORM or IoC container, or we could try and do a static, opaque or service located dependency directly inside our entity: public class Order { public decimal CalculateTotal() { decimal itemTotal = GetSubTotal(); decimal taxTotal = TaxService .CalculateTax( this ); decimal discount = DiscountCalculator .FindDiscount( this ); return itemTotal + taxTotal - discount; } In this snippet, we have an Order entity that is apparently responsible for calculating up-to-date tax and discount information.  We’ll get back to that cluster in a second.  First order of business, how do we deal with these two dependencies, the TaxService and DiscountCalculator?  A few options include: Static...

  • Crafting wicked domain models with Components in DDD by Jimmy Bogard

    Domain-Driven Design can help focus development efforts into crafting a strong, expressive domain model.  In Evans’ book, he dives in to a series of patterns which, when combined, form that strong domain model.  These patterns include Entity, Value Object, Service, Factory, Repository, Aggregates and Roots.  I think one of the biggest mistakes of someone learning and applying DDD is assuming that our entire model needs to fit into those few definitions. When you do so, you wind up in spots where you’re trying to use a Repository from inside an Entity, or violating other more basic OO design principles.  When you’re feeling like you’re bending over backwards to fit everything into one paradigm, it’s time to stop, take a step back, and try a different angle.  The GoF design patterns book introduced a lot more patterns than described in Evans’ book, and all are valid inside the domain.  We shouldn’t artificially limit ourselves to the patterns in Evans’ book, as it was never meant to be an exhaustive domain patterns library.  Many times, what looks like a DDD problem is just an OO problem hiding in plain sight. One example I’ve seen of a powerful OO design concept not explicitly called out is the Component...

  • VAN Talk *TODAY* by Greg

    I will be doing a talk today for Alt.Net Europe's VAN program You can find out more information on the talk including the livemeeting address here http://elegantcode.com/2009/01/29/european-virtual-altnet-meeting-on-02022009/ I will be talking about command query separation in DDD based systems. There has been a lot of talk recently about this on the DDD list and after explaining the basics of how things can work I will address some of the questions that have come up. Hope to "hear" you there Read More...