DDD Step By Step
A Practical Guide to Domain Driven Design

September 2009 - DDD on the Web

Sort by: Most Recent | Most Viewed | Most Commented

  • Beating the duct programmer with generic domains, subdomains, and core domains by Ian Cooper

    There has been a certain amount of noise and comment around Joel Spolsky's post on the duct tape programmer . This is, for me, just another manifestation of the hero coder - the guy the business love because he 'gets things done'. He is the guy who is turning out the features to the customer while you are still implementing top down from your acceptance to your unit tests. While you are trying to build a domain model, focusing on the ubiquitous language, and trying to create a model expressed in software, he has hacked out some procedural code that just works. While you create your ORM mappings in Fluent NHibernate, his DataReader has grabbed everything he needs from a custom stored procedure and pumped out the web page. In the customer's eyes he is responsive, he gets their needs, and you don't. The trouble with the hero programmer is that the customer does not know he uses duct tape, and your explanation of why it is an issue anyway is so complicated they lose interest. The truth is they just don't care about your engineering principles. And the worst of it is that he will go on to write new features, while you fix up his last duct-tape special, because he is the guy the customers want, the hero programmer...

  • DDD - Videos online

    The videos of my DDD talk earlier this year have been posted on chopsticks. So in case you the session, you might want to have a look at them... Read More...

  • Drawing the Line Between MVC Controllers and DDD Application Services by Billy McCafferty

    Frequently, when we adapt new technologies or techniques, the new fix ends up introducing new "yucky" stuff or simply pushes the previous yucky stuff to another area. Since "yucky" might be a bit technically subjective here, I consider yucky stuff to include any bit of code that has no clear home or which is overly complicated for the sake of separtion of concerns. If you encounter code such as this, it doesn't necessarily mean that you have a weak understanding of the domain or task at hand, but it may be a sign that you have a grey area between application layers which needs to be better defined. These grey areas are frequently found between where the presentation layer ends and the controller and/or business logic begins. For example, when we moved from Active Server Pages to ASP.NET, we liberated our views of business logic only to find our newly embraced code-behinds to be a bear to maintain as they intertwined abstracted presentation concerns with logic. Adding a pattern such as M V P certainly made it all testable but then moved much of the "yucky" stuff to either the presenter class or added new yucky stuff in the form of complicated event communications and/or fudgy controller logic between...

  • Alt.Net Evangelism And What We Could Do Better by Ryan Svihla

    If we assume our goal as the Alt.Net community is to improve software development as a whole, we're doing a pretty bad job. Not that many people have even heard of the concepts we espouse, and those that have but didn't convert become hostile to our ideas. My theory is because we focus so much on things that at the surface seem extraordinarily complex. Our terminology while correct, is acryonym laden and hard to grasp the real meaning. We ourselves sometimes lose site of why we even care about some of those principles, why we enacted them in the first place and what pain they caused to begin with. I'm not the first person to say or think this, but this has really hit home with me lately since now I get to talk to developers who are brilliant, talented and overall effective at what they do but who consider XP+SOLID a bunch of "enterprise junk" that fights against "natural coding" and my personal favorite "Unit testing is just testing your tests" . I've tried to talk to people in a reasonable way when I hear things like this, but usually before I know it, the alphabet soup of acronyms is out of my mouth, BDD, DDD, on and on. Even as a hungry student those terms shut my brain down when I first...

  • It's turtles all the way down by Ian Cooper

    Normal 0 false false false EN-GB X-NONE X-NONE MicrosoftInternetExplorer4 Classically an ORM persists an object model to a relational model. Typically just use it to retrieve or persist the state of the objects in our model, not provide integration through models. Though obviously there is some translation between the models in the act of persistence, the greater distance between the two models the greater the effort we have to expend on the persistence mapping. This becomes an issue when we are tempted by using a shared database schema as a mechanism for system integration. The approach is simple in concept: two systems with differing models, communicate by virtue of the fact that they share a relational schema. In Hohpe's Enterprise Integration Patterns , Martin Fowler calls this integration style Shared Database . The two systems don't exchange information, they share information. Shared Database seems an attractive way to integrate systems within your enterprise at first. You do not have the complexity multiplier of distributed systems and the skills sets required to make them work. Corporate MI does not have to map between models to report, it just points to an reporting store created from the shared repository (or in...

  • Progressive .NET Wrap-up by Udi Dahan

    So, I’ve gotten back from a most enjoyable couple of days in Sweden where I gave two half-day tutorials, the first being the SOA and UI composition talk I gave at the European Virtual ALT.NET meeting (which you can find online here) and the other on DDD in enterprise apps (the first time I’ve done [...] Read More...

  • DDD: Repository Implementation Patterns by Jimmy Bogard

    One of the major structural patterns encountered in DDD (and one of the most argued about) is the Repository pattern .  You’ve created a persistent domain model, and now you need to be able to retrieve these objects from an encapsulated store.  In Fowler’s PoEAA, the Repository pattern is described as: Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects . In many DDD implementations, the use of a Repository is widened to go beyond retrieval, but the other pieces in the CRUD acronym.  This is natural, as a Repository provides a centralized facade over some backing store, whether that backing store is a database, XML, SOAP, REST and so on.  But what about the actual interface of the Repository?  What kinds of options do we have for designing the actual Repository itself?  There are quite a few different schools of thought here, each with their own benefits and drawbacks. The Generic Repository Interface In the generic repository interface, the interface definition itself is generic, with implementations for individual entity types.  The generic type parameter denotes the entity type of the repository.  One example is in S#arp Architecture...