DDD Step By Step
A Practical Guide to Domain Driven Design

December 2009 - DDD on the Web

Sort by: Most Recent | Most Viewed | Most Commented

  • Much Ado About Monads – State Edition by Matthew.Podwysocki

    Over the past year, I’ve had the opportunity to be a technical reviewer of a number of books including Chris Smith’s Programming F# book .  During my recent trips, I had the chance to sit down and read through the book once again, and in particular Chapter 10 on Computation Expressions (aka Monads).  A section worth noting in here is the use of the State Monad in order to create a library for web scripting.  In the past, I’ve had a series on Much Ado About Monads where I look at the basic Monads such as Maybe and List, but this time, let’s look at what we can do with the State Monad. Keeping Track of State Before we get started looking at the state monad and what it entails, let’s look at the overall goal.  What are we trying to solve?  Taking the example of the web scripting DSL, as we perform actions such as clicking a button, we change the state of the system and this state is returned to use each and every call.  This state then needs to passed along to the next step for processing.  This state becomes cumbersome as we have to manage it for each and every call in our function.  What we end up with is a messy API that looks like this: [ < Fact > ] let ``Can find CodeBetter on Bing``...

  • Overriding generic component’s resolution in Castle Windsor by Krzysztof Koźmic

    Few months ago, a user asked the following question on the Castle users discussion group. A friend asked me about the same thing today, so I thought I’d blog this so that’s easier to find than the discussion group thread. Anyway, here’s the question: say I have the following types public interface ISometype<T> {} public class SomeTypeImpl<T>:ISometype<T> {} public class SomeSpecificTypeImpl<T>:ISometype<T> where T: ISomeSpecificSpecifier {} public interface ISomeSpecificSpecifier { } Is there a way to register ISomeType<> in the container so that for the general case it uses SomeTypeImpl<> but for cases where T is ISomeSpecificSpecifier it could use SomeSpecificTypeImpl<>? Solution take one – the explicit version The solution may be similar to the following sketchy code. class Program { static void Main( string [] args) { var container = new WindsorContainer(); container.Register(Component.For( typeof (ISometype<>)).ImplementedBy( typeof (SomeTypeImpl<>)), Component.For( typeof (ISometype<>)).ImplementedBy( typeof (SomeSpecificTypeImpl<>)) .PreferredFor<ISomeSpecificSpecifier>()); var selector = new Selector(); container.Kernel.AddHandlerSelector(selector...

  • Persistence model and domain anemia by Jimmy Bogard

    Domain anemia is a term thrown around like it’s a horrible disease.  However, a while back, Greg Young talked about an intentional decision to create an anemic domain model .  In some contexts, an anemic domain model is an anti-pattern .  Instead, I see a rather different issue going on here.  For the vast majority of systems built that I’ve encountered, a true domain model is overkill.  But what is the domain model pattern?  It could be all the way to a CQRS system , or it could be a system where your entities are more than containers of data, but containers of behavior. The real problem is the assumption from folks doing an anemic domain model that they’re doing DDD or doing a domain model pattern.  But if your entities only expose data, it’s not a domain model.   This isn’t necessarily a bad thing though.  It’s more important that this decision is intentional. Anemic domain model has a negative connotation, so I’d like to get rid of that term used to describe the intentional decision to create an anemic model.  Instead, I like the term Persistence Model or Persistent Object Model to describe an intentionally anemic domain model. The Persistence Model Pattern In the Persistence Model...