DDD Step By Step
A Practical Guide to Domain Driven Design

DDD on the Web

Sort by: Most Recent | Most Viewed | Most Commented

  • Strengthening your domain: Encapsulated collections by Jimmy Bogard

    Previous posts in this series: A Primer Aggregate Construction One of the common themes throughout the DDD book is that much of the nuts and bolts of structural domain-driven design is just plain good use of object-oriented programming.  This is certainly true, but DDD adds some direction to OOP, along with roles, stereotypes and patterns.  Much of the direction for building entities at the class level can, and should, come from test-driven development.  TDD is a great tool for building OO systems, as we incrementally build our design with only the behavior that is needed to pass the test.  Our big challenge then is to write good tests. To fully harness TDD, we need to be highly attuned to the design that comes out of our tests.  For example, suppose we have our traditional Customer and Order objects.  In our world, an Order has a Customer, and a Customer can have many Orders.  We have this directionality because we can navigate this relationship from both directions in our application.  In the last post, we worked to satisfy invariants to prevent an unsupported and nonsensical state for our objects. We can start with a fairly simple test: [ Test ] public void Should_add_the_order_to_the_customers_order_lists_when_an_order_is_created...

  • Profiling Apps 1 of N: The MVC ActionLink by Hadi Hariri

    I’m starting a new series of blogs posts on profiling, where we’ll try and cover common bottlenecks and how to identify them in your applications. However, before delving deeper into the subject, let me make a small but important observation: Your bottleneck is probably not your for loop Now, replace that for loop with switch statement , an older version of some outdated algorithm that you feel needs optimizing, or that retched collection of classes that would perform better if you were using an array to loop through them, and you’ll end up with the same observation. Premature Optimization When dealing with business applications, it is unusual for major performance problems to be pinpointed down to specific portions of code or a concrete implementation of an algorithm. Usually most of the issues are bottlenecks at the data level, network level or purely down to how a business decision is made. Whether we use an ORM or use SQL directly, incorrectly formulated queries are one of the most predominant causes of bad performance. Not understanding concepts such as Lazy or Eager loading when using an ORM can be disastrous to the performance of an application, and are usually portrayed as “ORM XYZ sucks at performance”...

  • Ubiquitous and unambiguous ? by pvanooijen

    My last musings on a observed misuse of ubiquitous language (UL) led to deeper comments than I had ever realized when writing the story down. To many a non native speaker ubiquitous is at first hearing a strange word, as far as I know it is not widely used outside the world of IT. The sounding reminds of (un-)ambiguous, a term often found in the same context. There is a relation between these two words and IMHO that was the heart of the comments and led me to take another dive into the idea of UL. The term Ubiquitous Language was brought to the world of software by Eric Evans in his classic book Domain Driven Design (DDD). Where it is defined as a language based on a model and spoken by both domain experts and developers. It should be “more robust than the lowest common denominator” (p.25). Domain experts “should object to terms or structures that are .. inadequate to domain understanding” and developers “should watch for ambiguity ..” (p.27) So a good UL is a powerful common unambiguous language spoken by all experts , whatever their background, to communicate on a software system. Note the stress on the word expert. Now some people involved are not an expert. Take the old lady in my previous story...

  • On Small Applications by Udi Dahan

    I hear this too often: “X sounds like a great pattern, but it’s overkill for small applications”. Many patterns have been subjected to this including (but not limited to): SOA, DDD, CQRS, ORM, etc. Often the statement is made by a person without experience in the given pattern (though possibly experienced in other patterns). Let’s [...] Read More...

  • The Biggest Driver For Domain Modeling Decisions by Michael Nichols

    I just read a post from fellow devlicio.us'er Billy McCafferty and was considering what influences my own solutions to these concerns (ie, repositories, data transfer, etc) now. There has been an abrupt shift/growth in my thinking this year in how I perceive my domain and how I interact with or scale it. CQRS, perceived by some as a shiny new toy, and the discussions it provokes has definitely contributed to the maturity of the project I have been on by increasing its quality and adaptability. Why? My experience has been the simple shift to being concerned about what all these things are doing (behavioral mindset) instead of what they look like (stateful mindset). I now see that the decision to expose domain state at all should be one of the first decisions to make and its implications on the various infrastructural concerns should be well-understood. This seems to drive divers decisions both within the domain and how it is consumed or utilized without. The first casualty of this shift was the getters and setters (whether exposed as properties or GetX()/SetX() methods). Hiding as much state as possible radically increases the freedom in the domain, especially when going down the event-sourcing route. As you know, the moment you...

  • A Few Thoughts on DDD, DTOs, View Models, CQS, Repositories and Separation of Concerns by Billy McCafferty

    What I've loved most about developing an open-source project is the ideas that I get from others who look at the work and either A) validate ideas, B) suggest that something stinks, or C) call a royal WTF and force people (e.g., me) to explain ideas more fully. It's usually during these explanation attempts that light bulbs start to come on and ideas are refactored and become more substantiated (or at least more defendable). The S#arp Architecture forums have been a gold mine, IMO, for the discussion of the practical application of balanced DDD techniques on real-world projects. After feedback that I've already gotten on my recent post concerning application services and CQS and listening to and adding my two cents concerning ideas on the S#arp forums, I'd like to share a few ideas (that I shared on the forum) concerning drawing the line among application layers, the management of DTOs and View Models, and a general discussion of separation of concerns. (As Chris Carter correctly explained , don't take these ideas at face value...use them as a point of discussion and contemplation to come to your own conclusions with your project team...and let me know what you think.) Every great developer knows that any problem...

  • Better Application Services and CQS using S#arp Architecture 1.0 Q3 2009 by Billy McCafferty

    Obviously, S#arp Architecture is the bee's knees when it comes to developing ASP.NET MVC applications. ;) But as a project evolves and gets larger, "out of the box" S#arp Architecture 1.0 guidance runs into a few pain points. Particularly, there's poor use of the application services layer, the separation between controllers and application services is not very clear, entity listing pages become performance bottlenecks as the domain model gets sizable, there is no command/query separation (CQS) "out of the box", and unit tests require re-occurring maintenance to deal with changes in the number of constructor parameters to controllers and application services. While the amicable and adroit Alec Whittington (who is taking over the lead role from me on S#arp Architecture) is hard at work upgrading S#arp Architecture to accommodate recent dependency upgrades and accommodating ASP.NET MVC 2, I wanted to take a stab at resolving some of the issues that I've run into, on S#arp projects over the past year. I've developed and included a sample project, built on S#arp Architecture 1.0 Q3 2009, for the following key reasons: To resolve some "pain points" that develop as S#arp projects grow to large...

  • Message-Based Systems for Maintainable, Asynchronous Development by Billy McCafferty

    Preface (you know it’s good if there's a preface) In Architectural Paradigms of Robotic Control , a number of architectures were reviewed including deliberative, reactive, and hybrid architectures. Each of these exhibit a clean separation of concerns with layering and encapsulation of defined behaviors. When implemented, the various capabilities, such as planners and mobility controllers, are encapsulated into discrete components for better reusability and maintainability. A pivotal aspect not discussed in the previous article is how the various system layers and components communicate with each other, such as reporting sensor feedback and sending commands to actuator controllers. Effectively resolving this communication challenge is not only important to robotic systems but to many other industries and domains for the successful integration of disparate applications. To give credit where credit is due, this article pulls quite heavily from the patterns, taxonomy, and best practices presented in Enterprise Integration Patterns (Hohpe, 2003). This well organized book is chock full of hard learned lessons and solid guidelines for developing maintainable message-based systems. This article should not be seen as an adequate replacement...

  • MSpec Live Templates by Hadi Hariri

    If you’re using MSpec ( Machine.Specifications ), you’ve no doubt run into the verbosity of it. Here’s a typical specification in MSpec [ Subject ( "Registering as new a usergroup" )] public class when_requesting_registration_page { Establish context = () => { }; Because of = () => { }; It should_display_blank_registration_form = () => { }; } The code is usually divided into three areas, the Establish that defines the context, Because which is defined as the action to take, and finally one or more benefits that are defined as It sections. Having this layout makes it easier to understand specifications and both the console runner as well as ReSharper’s MSpec runner remove underscores and provide a nice formatting. Live Templates However when it comes to typing all this in, well all those brackets and symbols become tiring. For that I normally use ReSharper Live Templates. If you’re not familiar with these, think of them as code snippets that allow interaction. Each template is uniquely identified by a shortcut, which is a series of characters. To invoke it, you simply type the characters and hit TAB. It then inserts some code. Up to this point it’s like a normal snippet. The twist...

  • Strengthening your domain: Aggregate Construction by Jimmy Bogard

    Our application complexity has hit its tipping point, and we decide to move past anemic domain models to rich, behavioral models.  But what is this anemic domain model?  Let’s look at Fowler’s definition, now over 6 years old: The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data. For CRUD applications, these “domain services” should number very few.  But as the number of domain services begins to grow, it should be a signal to us that we need richer behavior, in the form of Domain-Driven Design.  Building an application with DDD in mind is quite different...

  • Transferred feed by Goeleven Yves

    To all of my loyal subscribers welcome back. I’ve transferred my original feed to this blog. From now on I will be talking cloud computing though and will no longer focus on Domain Driven Design, there is enough content on that topic nowadays anyway. But if you’re interested in cloud, and particulary windows azure, stay tuned… [...] Read More...

  • CQRS, Task Based UIs, Event Sourcing agh! by Greg

    Many people have been getting confused over what CQRS is. They look at CQRS as being an architecture; it is not. CQRS is a very simple pattern that enables many opportunities for architecture that may otherwise not exist. CQRS is not eventual consistency, it is not eventing, it is not messaging, it is not having separated models for reading and writing, nor is it using event sourcing. I want to take a few paragraphs to describe first exactly what CQRS is and then how it relates to other patterns.   CQRS Command and Query Responsibility Segregation Starting with CQRS, CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation, a command is any method that mutates state and a query is any method that returns a value). When most people talk about CQRS they are really speaking about applying the CQRS pattern to the object that represents the service boundary of the application. Consider the following pseudo-code service definition. CustomerService void MakeCustomerPreferred(CustomerId) Customer GetCustomer(CustomerId) CustomerSet GetCustomersWithName(Name) CustomerSet...

  • [ANN] DC ALT.NET: 2/24 - Getting the Right System with George Dinwiddie by Matthew.Podwysocki

    The next DC ALT.NET meeting is taking place on 2/24/2010 from 7-9PM.  Stay tuned to the mailing list for more information as it becomes available.  In this meeting, once again we have George Dinwiddie, to give a talk on talk in the language of the business and what tools along the way can help us.  Below is a description of the event.  We hope to see you there! This year we have a lot of great sessions in store including Mono, Domain Driven Design, Git and other DVCS for the .NET developer, more JavaScript topics and a lot more.  If you’re in the Washington, DC area, sign up for the list and hopefully you can join us. A ''Lingua Franca'' to Ensure You Get the Right System The business tells the IT department what it wants. The developers build it. The testers expect it to do something different. And neither of these turn out to be what the business had in mind. Has this ever happened to you? IT departments have always struggled with getting clear and unambiguous requirements. Automated acceptance tests that check the system with examples make a big impact on coordinating the work of developers and testers. Unfortunately, they’re often incomprehensible code to the business people asking for the...

  • CI and Google App Engine, or “How to force your way in” by Kyle Baley

    If you’re the type that skips titles, we’re using Google App Engine in our project, mostly because it’s there. I jest. We’re using it because it’s scalable and high performance and reliable and whatever other reason you can think of that will keep me from having a boring debate on the difference between Google and Amazon and Microsoft. Along with Google App Engine, we’re also using TeamCity for our continuous integration server. And generally speaking, these are two very disparate topics. I.e. I’m not finding App Engine to be very CI-friendly. Deploying to App Engine from Eclipse or IntelliJ is dead simple. There are plug-ins that manage it and all you do is provide credentials. Doing it from the command line is not too bad. There’s a console utility, appcfg, that lets you upload to App Engine. So on the surface, it appears CI and App Engine play nicely. But there are a couple of quirks that don’t sit well. We’ll start with the Ant tasks I’m using from the CI server: <target name="setAppEngineVersionToDayOfWeek"> <tstamp> <format property="day.of.week" pattern="E" /> </tstamp> <stringutil string="${day.of.week}" property="day.of.week"> <lowercase/>...

  • cqrs for dummies – 1 of N – the query layer by John Nuechterlein

    Back to the fun stuff. Series link here . As a reminder of what I’m talking about, here’s the picture from Mark : What I’m going to be talking about is section #1 from Mark’s picture, and in particular, I’m going to going over a number of concepts including: The Reporting Store Eventual Consistency You don’t need your Domain Once you have one, why not more? “Reporting” doesn’t just mean Reporting One of the first things that I found difficult when learning about CQRS was the use of the term “Reporting.” Because I come from a SQL background, when I hear the term “Reporting” in IT contexts, I think about reports, e.g. last month’s sales report. Because of how the term is normally used, I’m not sure if there is a different word that should be used here. However, especially with all of the stuff I just wrote about traditional reporting, there are a couple of concepts that are starting to make more sense to me, since it turns out that some of the concepts of CQRS are simply things that we’ve been doing already, but refined. The first thing to keep in mind is this: The Reporting Store (as separated from the Event Store, which is up in section #3 of the picture) is a logical concept, and as such does not have to be physically separated. Having...
1 2 3 4 5 Next > ... Last »