The ParisJug organized a DDD event yesterday in  Paris presented by Eric Evans, the author of Domain  Driven Design himself.

He’d come in France ten years ago, but never made a presentation about Domain Driven Design here yet.

Thanks to Antonio and Nicolas and the others and who organized this presentation in 4 days. You can find a summary of the talk in French here.

Putting the model to work

It was the title of the talk. I’ll not make a full report since it was mainly what’s in the book for those who had not grasped the concepts of DDD yet.

I’ll talk about important topics of the content in following posts.

Diner with Eric Evans and Jug guys

After the presentation, we moved to a restaurant with Eric Evans, the organizers and other attendees. I had the chance to be at the same table as Eric, so I had the opportunity to talk with him about a lot of things.

He’s not at all the Pattern Guru kind. Very careful to let you understand he’s not found a solution to your problems, that you’ll have to work, but that his experience and analysis can help to grasp things a bit more clearly. He’s constantly working hard on several project to get more experience and set his knowledge and experimentation against different contexts.

I’ll also talk about part of our discussion in following posts.

I had quite a lot of comments on my previous post on repositories and paging, and there’s a lot of people coming from google looking for answers… It’s sign that there’s no good response to this issue now.

The problem was how paging (a presentation concern) fits into a repository that should have only domain concerns…

And the short answers is… It doesn’t fit !

It doesn’t mean you should forget everything I told you before but there’s a vision change.

There’s something missing in DDD book…

but present in current discussion about DDD. The book provides good building blocks (entities, repository…) but Evans says himself it has been a bit over emphasized. The book is mainly about maintaining and mutating your domain state, not about it’s presentation.

CQS to the rescue

The CQS (Command Query Separation) principle proposes to decouple Commands that change the state of the system, from Queries that ask the state of the system.

The repository lies on the Command side, that’s why :

• It should be specialized to express only mutations that are possible for the system
• It should not expose presentation concerns like paging

But what’s on the Query side ?

The query side should be far more supple and provide tools to query the state of the domain. It can even be implemented with IQueryable interfaces to provide that flexibility. Asking for pages in this area is natural since you just want to query a part of the domain state.

The goal of all this is to report the state of the system. So Reporting is a good name here.

You can read Greg Young’s DDDD posts to see where CQS can lead : Write only domain model (Commands) and rich scalable distributed Query mechanisms using messaging.

There’s no clear guidance yet in this field but I’m still investigating. The flexibility of a reporting service in the domain layer is still a huge gain to understand where each concept fits.

I’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 :

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.

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.

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

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

In your repository implementation you can then use all this :

The last part is in the implementation of the builder.

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.

Marcel posted a comment in the previous post saying that even if returning IEnumerable, the new query clauses would be executed in the database… But it’s not.

If the repository use linq internally and returns the result as IEnumerable, on the other side, consider something like this :

Where GetAll returns an IEnumerable (that is actually a IQueryable).

The Where extension method will be selected on Enumerable. Be careful, Extension methods are static methods, no virtual call is involved here. The static type of the object decide the selected extension method.

Check in your debugger, selectedEntities is an instance of the Enumerable.WhereIterator internal class.

So when enumerating it, it enumerates its source and returns every item that passes the predicate.

When enumerating the source, here the source use linq2Sql to get the items and creates a query that returns all rows from the database.

The where clause was not executed in the database.

So the Linq provider did not leak outside of the repository.

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

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