Think Before Coding

To content | To menu | To search

Tag - Domain Driven Design

Entries feed - Comments feed

Thursday, March 12, 2009

QCon London 2009

Today, there's a full QCon London track dedicated to Domain Driven Design.

Eric Evans exposed this morning what he's learned about DDD since the book, and lots of interesting things.

Gojko Adzic posted a report of Evans' talk.

The whole slides should be available on QCon site shortly.

You can also follow in on twitter through Richard Banks reports.

 

Wednesday, March 4, 2009

How *not* to inject services in entities

syringeI’ve seen lot of people asking where and how to inject services in entities. The services in question are often repositories by the way…

The response is simple :

 - DO NOT inject services in entities !

- Ok I see, you’re against dependency injection

- NO, I'm not against dependency injection, I use it a lot.

- You can still use a static service locator…

- I avoid service locator when I can, especially when the service locator must be static…

– So you’ll get an anemic object model !

- I don’t think so.

 

Injecting services in entities is wrong

You’ll find me a bit presumptuous, but I say it again : Injecting services in entities is wrong.

Nesting objects is not a problem from an OO point of view, but we’re talking about a special kind of objects, entities.

 

Entities are all about their state management, and this state management can require several objects.

  • Code infrastructure objects like lists or dictionary to handle collection of data,
  • Object oriented constructs to leverage code maintenance techniques like strategies.

Entities don’t have to be classes with public setters and getters… you should even avoid this to keep you entities in a consistent state.

But there is no reason for an entity to keep a reference on a service, since it’s not part of its state.

There are usually three situations in which people thinks they need it :

  • Lazy loads
  • Relations
  • Behavior methods

Let’s review each point…

 

Lazy loads

Sometimes, an entity property is heavy to load and is not required by all code paths. In this case, loading it upfront can lead to performance problems.

The usual way to work it out is to hold a reference to a data access object or a repository and to load and cache the requested data on demand.

 

 Using a data access layer object in the entity is clearly a break of persistence ignorance, but using a repository is not a better option.

 

The repository is a way to abstract persistence in the model, but it’s still a persistence concern even if modeled in terms of domain terms.

I’ve already posted about ways to solve this problem in Lazy load and persistence ignorance and part 2.

 

Relations

I was twitting yesterday with Kyle Baley about the need to have an Event repository in the Users entity. He wanted to get the User Team for the current event. I think you don’t need more context to understand the problem.

The User did not know about the current event so it needed the Event repository to find it and find the corresponding team.

But why does the User entity expose a CurrentTeam property if it doesn’t know about Events ? There’s something missing here.

The whole picture becomes clearer if you add a Participant entity that embodies the participation of a user to an Event, and no repository is needed anymore since you don’t need a CurrentTeam property on User.

 Make relations clear instead of hiding it in repositories.

 

Behavior methods

If I have mail message entity and I want a Send method on it ?

Tiding your entity to the service that will use it is not conceptually satisfying. The server that will send the message is a medium and is not part of the entity itself.

It’s seems better to call server.Send(message).

The problem is that you can end breaking the tell don’t ask principle because the Send method will ask the message for each property value. And you can be tempted to put computations that should be in the message entity inside the Send method.

 

Let’s call Double Dispatch to the rescue !

  • Design a server interface presenting a Send method that take the parameters it need (title, recipients, message body…)
  • Add a SendThrough method to your entity that takes the server interface as parameter
  • Implement SendTrhough so that it computes values to pass to the Send method
  • That’s it.

 

Here is a small sample implementation :

    public interface IMailService

    {

        void Send(string sender, string recipient, string subject, string body);

    }

 

    public class Message

    {

        //...

        public void SendThrough(IMailService mailService)

        {

            string subject = isReply ? "Re : " + title : title;

            mailService.Send(sender, recipient, subject, GetMessageBody(content));

        }

    }

The entity is not tied to the service before needed. So no need for injection.

 

Is injection useless ?

There is no problem to inject services with other services, and it’s even easier since services have no state, they only need their dependencies in constructor, and to my opinion it’s the cleanest injection mode.

Usually domain services will need infrastructure services dependencies, and in this case a dependency injection framework can make things easier.

Following the preceding advice, you’ll never need to use your dependency injection framework as a service locator, and you’ll never have to perform buildups on your entities, and you’ll feel much better.

 

What’s your way to deal with it ?

For now I’ve always find a way to get rid of services inside entities, but I really would like to hear cases where you’re stuck with it to see if another way is possible, or cases where you think there is really a good reason to go this way.

Tuesday, February 24, 2009

Domain Driven Design Step By Step

Casey Charlton is moving his DDD series on a wiki site so that every body can put it’s personal touch.

You can find it and participate at : http://dddstepbystep.com/

Expect me to write there !

Sunday, February 8, 2009

Lazy loads and persistence ignorance (Part 2)

In the previous post, I introduced a class to manage function injection for lazy loads to enable persistence ignorance.

Chris was asking where the builder I was talking about should be used, and I tumbled on a StackOverflow question asking how to make lazy loading without using classes like Lazy<T>...

I'll discuss the second part first.

There is a good way to make lazy loading without using classes like that. You can use proxies.

There are two main ways to make transparent proxies

  • by creating dynamically a derived class using Reflection.Emit
  • by creating a transparent proxy

Still there are some drawbacks with both approaches. For the first one, all your members should be made virtual, for the second your class should inherit from MarshalByRefObject. In all case you should then take care not to mess up between proxies and underlying classes.

The main critic to refuse to use Lazy<T> class is usually that it's not a domain concept, and that it leaks persistence concern in the model.

I reject those critics.

Have you ever seen someone criticize List<T> or Dictionary<,> because it was not a domain concept ? We're writing OO code, and we can use basic tooling to make our models expressive. IEnumerable<T> and Linq to objects are good examples of these useful tools.

And I don't consider that Lazy<T> is a persistence concern. It expresses that the relation between entities is a bit more loose than others. There is nothing in the Lazy<T> signature that ties your entity to any persistence concept. You just provide a way to give the value of the property when needed rather than at construction, but this choice comes from outside of your entity.

And at least it becomes clearer than with derived proxies where the C# keyword virtual is used to express something but tries to hide it in the same time.

 

For Chris question, I use the builder in the repository.

The repository is responsible for retrieving entities from the data store. The reconstruction of objects is a bit different from the construction. This is underlined in Evan's book in the chapter Factories / Reconstituting Stored Objects.

In my data access layer I use a IDataBuilder<T> interface that represents a service that can build an object of type T from a IDataRecord. This is when I work directly with the ADO.Net and stored procedures.

    public interface IDataBuilder<T>

    {

        T Build(IDataRecord record);

    }

 

I also use a class that encapsulate the access to the stored procedures (or queries if you don't want to use stored procedures).

    public class DataAccess

    {

        public UniqueResult<Entity> GetEntity(Guid id);

        {

            //...

        }

 

        public MultipleResult<Entity> GetEntities()

        {

            //...

        }

    }

 

UniqueResult<T> and MultipleResult<T> provides a methods that take a builder to read data records :

    public struct UniqueResult<T>

    {

        public T With(IDataBuilder<T> builder)

        {

            //...           

        }

    }

 

    public struct MultipleResult<T>

    {

        public IEnumerable<T> With(IDataBuilder<T> builder)

        {

            //...           

        }

    }

 

In your repository implementation you can then use all this :

    // The concrete repository interface that belongs to the domain

    public interface IEntityRepository : IEnumerable<Entity>

    {

        Entity this[Guid id] { get;}

        //.. other methods

    }

 

    // the implementation that is not part of the domain

    // an that is pesistance dependant.

    internal class EntityRepository : IEntityRepository

    {

        private DataAccess dataAccess;

        private EntityBuilder builder;

 

        public EntityRepository(DataAccess dataAccess, EntityBuilder builder)

        {

            this.dataAccess = dataAccess;

            this.builder = builder;

        }

 

        public IEnumerator<Entity> GetEnumerator()

        {

            return dataAccess.GetEntities().With(builder);

        }

 

        IEnumerator IEnumerable.GetEnumerator()

        {

            return GetEnumerator();

        }

 

        public Entity this[Guid id]

        {

            get { return dataAccess.GetEntity(id).With(builder); }

        }

    }

 

The last part is in the implementation of the builder.

    internal class EntityBuilder : IDataBuilder<Entity>

    {

        private DataAccess dataAccess;

 

        public EntityBuilder(DataAccess dataAccess)

        {

            this.dataAccess = dataAccess;

        }

 

        public Entity GetEntity(IDataRecord record)

        {

            var id = (Guid)record["Id"];

            return new Entity(

                id,

                Lazy.From(() => dataAccess.GetSubEntity(id)));

        }

    }

 

Of course, the repository implementation, the DataAccess class and the builder are all internal to the data access implementation. It can be in a separate Assembly or internal in a sub namespace of the main assembly depending on you module separation preferences.

When using linq, you simply don't need the DataAccess class because you can query the DataContext directly. But you can use the same pattern.

The main point is still that your Entity object knows strictly nothing about what's going on there.

Saturday, February 7, 2009

Lazy load and persistence ignorance

lazy

I often see questions about how to make lazy loads in entities, and wether using dependency injection for it.

The usual response is something like this :

    class Entity

    {

        private Guid id;

        private SubEntity subEntity;

        private IDataService dataService;

 

        public Entity(Guid id, IDataService dataService)

        {

            this.id = id;

            this.dataService = dataService;

        }

 

        public SubEntity SubEntity

        {

            get

            {

                if (subEntity == null)

                    subEntity = dataService.GetSubEntity(id);

 

                return subEntity;

            }

        }

    }

As you can see, your entity is seriously tied to your persistence problem now. Even if it accesses the persistence layer through an interface, it is not persistence ignorant anymore.

The smell is that you cannot create an in memory instance of your entity anymore without worrying about data access.

Should you sill inject the data access service, or is it useless and you should leave it null ?

So believe me : do not inject data services in your entity.

Now, how can we still have the lazy load behavior ?

Through injection. But not dependency injection, I use execution inversion of control through delegate injection.

If you give to your entity a function that will return the value when asked, it's as if you gave the value.

Let's encapsulate this in a small class :

    public class Lazy<T>

    {

        private T value;

        private Func<T> loader;

 

        public Lazy(T value)

        {

            this.value = value;

        }

 

        public Lazy(Func<T> loader)

        {

            this.loader = loader;

        }

 

        public T Value

        {

            get

            {

                if (loader != null)

                {

                    value = loader();

                    loader = null;

                }

                return value;

            }

        }

 

        public static implicit operator T(Lazy<T> lazy)

        {

            return lazy.Value;

        }

 

        public static implicit operator Lazy<T>(T value)

        {

            return new Lazy<T>(value);

        }

    }

Then you can use it like this in your entity :

    class Entity

    {

        private readonly Guid id;

        private readonly Lazy<SubEntity> subEntity;

 

        public Entity(Guid id, Lazy<SubEntity> subEntity)

        {

            this.id = id;

            this.subEntity = subEntity;

        }

 

        public Guid Id { get { return id; } }

 

        public SubEntity SubEntity

        {

            get { return subEntity; } // implicit cast here

        }

    }

The code is more straight forward, the intent is clearly visible.

One benefit here, is that the subEntity field can be marked as readonly, that is a big improvement because our entity is really immutable now. Actually the Lazy<T> is mutable, but it behaves as an immutable value.

If your entity is not immutable, you can still leverage the Lazy<T> class :

    class Entity

    {

        private readonly Guid id;

        private Lazy<SubEntity> subEntity;

 

        public Entity(Guid id, Lazy<SubEntity> subEntity)

        {

            this.id = id;

            this.subEntity = subEntity;

        }

 

        public Guid Id { get { return id; } }

 

        public SubEntity SubEntity

        {

            get { return subEntity; } // implicit cast here

            set { subEntity = value; } // implicit cast here too

        }

    }

The last part is about how you use it when instantiating the object.

When creating a new instance in a factory (not linked to database) :

            SubEntity subEntity = ...;

            Guid id = ...;

            Entity entity = new Entity(id, subEntity);

Here again, the implicit cast happen to pass the SubEntity as an already loaded Lazy<SubEntity>.

When binding the entity to the database :

    class EntityBuilder

    {

        private IDataService dataService;

 

        public EntityBuilder(IDataService dataService)

        {

            this.dataService = dataService;

        }

 

        public Entity GetEntity(Guid id)

        {

            return new Entity(

                id,

                new Lazy<SubEntity>(() => dataService.GetSubEntity(id)));

        }

    }

We can use a small helper method to make the instantiation cleaner :

    public static class Lazy

    {

        public static Lazy<T> From<T>(Func<T> loader)

        {

            return new Lazy<T>(loader);

        }

    }

Then you can write :

            return new Entity(

                id,

                Lazy.From(() => dataService.GetSubEntity(id)));

 

Now, the code that instantiate the Entity decides where the sub entity comes from.

The entity has become truly persistence ignorant.

Some would also advice not to use lazy load at all... this is still an option to consider !

Continued in Lazy loads and persistence ignorance (Part 2)

Monday, January 19, 2009

Repositories and IQueryable, the paging case.

Edit : My opinion on this subject have changed… You can read the full story in Back on Repositories and Paging. Introducing reporting.

The technique is still useful to write the query services, but I would not recommend to implement it on a repository.

 

When it comes to repositories, people have a hard time figuring how to respect the DDD vision while taking most out of current ORM technologies (Linq and ORM) and not writing too much code – we’re so lazy.civilwar

The war between IRepository<T> generic repositories or not is raging outside, and I took some time to chose my side. Here are the points to consider :

  • The repository is a contract between the domain and the infrastructure
  • The implementation details should not leak outside

In my opinion, the first point indicates that the repository should be tailored to the domain needs. It cannot be generic, or it is not a contract at all.

When writing a contract, details matter !

This doesn’t mean that we cannot use generic tools to access data behind the interface curtain. Linq DataContext and Tables<T> are very sharp tools to implement repositories. And there is a very good post by Greg Young about that.

 

There is still a point to be discussed though :

Should the repository methods return IEnumerable<T> or IQueryable<T> ?

The IQueryable<T> is part of the framework, and cleanly integrated in the language.

The problem is that its implementation depends heavily on the underlying provider. And it is a really serious leak !

So lets state the question differently :

- Why would we need IQueryable ?
- Because we can add new query clauses, and they will be executed directly in the database.

- What kind of clause would you add ?
- Don’t know… clauses…

- Would it be business specifications ?
- No, these should already be in the repository..

- So ?
- Sorting and Paging ! These are presentation concerns !

- Here’s the point.

Paging is not a recent concern for programmers and there is never enough tools to implement it properly. The main problem is that paging once you’ve got all the data is less that effective. And this is what will happen with an IEnumerable approach.

But let’s ask a two last questions.

Why is paging useful ? Is it really a presentation concern ?

We need paging to navigate through large collection of object, and if a collection can grow enough so that is cannot be embraced in a single query, it becomes a domain concern !

  • When your object collection is known at design time to stay in small bounds but you still want to page it for presentation clarity, there is no real penalty to fetch all and display only a few.
  • But when your collection can grow big, you SHOULD provide a mechanism to retrieve only a range of it, for presentation purpose or simply for batching purpose.

The problem is that if we leak IQueryable, the user can do far more than paging, and problems can arise. So I suggest to use a new interface IPaged<T> that would provide everything needed for paging :

public interface IPaged<T> : IEnumerable<T>

    {

        ///<summary>

        /// Get the total entity count.

        ///</summary>

        int Count { get; }

 

        ///<summary>

        /// Get a range of persited entities.

        ///</summary>

        IEnumerable<T> GetRange(int index, int count);

    }

 

And here is a simple implementation on a IQueryable :

public class Paged<T> : IPaged<T>

    {

        private readonly IQueryable<T> source;

 

        public Paged(IQueryable<T> source)

        {

            this.source = source;

        }

 

 

        public IEnumerator<T> GetEnumerator()

        {

            return source.GetEnumerator();

        }

 

        IEnumerator IEnumerable.GetEnumerator()

        {

            return GetEnumerator();

        }

 

        public int Count

        {

            get { return source.Count(); }

        }

 

        public IEnumerable<T> GetRange(int index, int count)

        {

            return source.Skip(index).Take(count);

        }

    }

Then your repository can return IPaged collections like this without leaking implementation details :

public IPaged<Customer> GetCustomers();

 

This seems to be a major step in the repository pattern understanding, and it’s underlying war. And you, on which side are you ?

Monday, December 22, 2008

DDD: Specifications

There's an interesting post by Greg Young about Specifications.

I'm currently refactoring some code to move constraints and validation in specification classes, and it really gives a better insight at what is constituting entities and what's not, especially when there are multiple level of constraints (persistence constraints, business constraints...)

Wednesday, December 10, 2008

Wow - Book review - Domain Driven Design!

Ok, I finished Domain Driven Design yesterday. I think I had no such Aha moment since I read Design Patterns eleven years ago...

I thought I was prepared for it, I had read many things to get maximum info...

I had :

I had practiced knowledge crunching on my own for long.

But the book go far beyond all that. It has a deep vision of programming on large scale projects, and give really good insight on difficulties that arise when working on complex systems with several teams. These are really precious pieces of advice.

The pattern presentation of the different chapters, even when those patterns are not implementation patterns but team organization patterns is really helpful and clear.

There is not much about implementation details, but it is not a problem. The principles are not tied to a specific technology or framework. Actually this is even a good point, it leaves the book clean from a specific implementation. Implementation books are aging faster.

You definitely should have this book on your shelf.

Tuesday, December 2, 2008

Domain Driven Design

I had read a lot of stuff about it these last months, and I think I got the essence and the principles.

I've received the blue book today.

I'm sure I'll have matter for blogging these days...

Monday, December 1, 2008

Ubiquity of language... lost in translation ?

I found two collapsing problems :

  • You should use the same language between domain experts and development teams (DDD)
  • You should use English for naming in your code (Design guidelines)

What if my domain experts don't speak English ?

page 2 of 2 -