Contents tagged with DDD

  • Domain Object and Contracts – The End

    In my previous blog about domain objects and contracts for those, I have described the situation where the team was thinking in a different way than myself, and what we tried. I have never blogged back about the fact that the team got convinced that this is not a good practice, and long time ago we stopped doing that. Today I spotted a blog post from James Gregory where he names it properly “an anti-pattern”. That’s what it is. End of the story.

  • State Pattern with FluentNHibernate

    FluentNHibernate is an amazingly nice DSL to use for quick NHibernate mapping implementation. Today I had to refactor some of the code we did at work, in order to persist a state of an object. The original code was implemented using State pattern, which allows simple division of responsibility and easy decision making at each given step. I have decided to create a simple example of State pattern persisted with FluentNHibernate in order to demonstrate how powerful it is and what kind of freedom it can give to developers.

  • Domain Object and Contracts

    As a team we have found ourselves in a very delicate situation where we had to make a group design decision and it was quiet an interesting experience. What happens if your opinion does not align with the decision? How do you express your opinion without suppressing others opinions, promoting your concepts without falling into the nasty habit of ignoring anything that is different?

  • IDs to Objects

    A few months ago I blogged about Domain Objects vs. Primitive Types. Back then it felt right to me to transform a primitive type, like a Guid that represented an organization ID, to an Organization domain object. Unfortunately at that time I was not educated enough to know that this is a common idiom among many object designers. Apparently it is. Craig Larman writes it nicely in his book (in my case Organization is what Craig references to as a Customer):