DDD Step By Step
A Practical Guide to Domain Driven Design

February 2010 - DDD on the Web

Sort by: Most Recent | Most Viewed | Most Commented

  • 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...

  • Strengthening your domain: a primer by Jimmy Bogard

    Recently, I talked some about the idea of an intentionally anemic domain model, under the name of “ Persistence Model ”.  While a Persistence Model is great for a large percentage of projects, you may eventually want to move more behavior into the domain.  That doesn’t mean a bevy of domain services doing the actual work, however.  A strong domain means that our objects become more behavioral, and less as solely data-holders. But before we get into some of the patterns, what are some of the goals we want to achieve with a stronger domain?  And how do we get there, what should we be looking for? Code smells A lot of DDD is just plain good OO programming.  Unit tests and code smells are the best indication that our domain is wrong, along with conversations with our domain experts.  In systems that start to move beyond merely CRUD, specific code smells start to surface that should indicate that our system is starting to accumulate behavior, but it just might not be in the right place.  In a behavior-rich, but anemic domain, the domain is surrounded by a multitude of services that do the actual work, and fiddle with state on our domain objects.  The domain objects contain state to be persisted, but...

  • An introduction to iptables by karl

    iptables is a linux application that allows you to configure the built-in linux firewall. There are abstraction layers built on top of it, including nice GUIs, but I recently had some very basic rules I wanted to implement, and figured I'd learn how to do it directly in iptables. It turned out to be easy to configure, and I thought I'd give a very basic introduction. First though, I relied on the ubuntu documentation to get up and running ( https://help.ubuntu.com/community/IptablesHowTo ). I'll pretty much just regurgitate what's in there - I've said it before, stop believing that linux documentation is written only for people who already know linux. Also, depending on your setup, most of these commands might require elevation (sudo). By default, iptables defines three rule chains: INPUT , FORWARD and OUTPUT . We'll only concern ourselves with INPUT - namely the chain used for incoming packets directed at this particular machine. At any point, you can list the rules by entering iptables -L . If listing the rules turns out to be really slow, try using iptables -L -n . The -n option means that the display will output IP addresses and ports in numeric format, without trying to do a DNS lookup. If the -n option...