As Romain was pointing in the comments, I totally missed to tell where I wanted to go with this static interface things. Need more sleep these days…

So here it is.

No I don’t want to do this

The point was not to enable something like this :

Static interfaces have no implementation exactly like interfaces.

With interfaces, you need an instance (usually in a variable or member) to find the actual implementation and call it. With static interfaces, you need a type.

There are two ways to specify a type:

• with its type name (Sample4.Count)
• with a generic type parameter (T.Count)

I was also proposing a way to specify a type for extension methods.

Where it would be useful - operators

The reason why everybody is asking for static members in interfaces is ultimately to have operators in interfaces.

Imagine :

Now you can write generic code like :

Cool !

This way, no need for the 20 overloads of Enumerable.Sum, it would work for any type presenting the expected static interface.

I read several discussions against Code ReUse and layered architectures recently :

• The Fallacy Of ReUse (Udi Dahan) 
• WebCast on SOA in the E-VAN (Udi Dahan)
• Feature by Feature (Oren Eini)

Different kinds of Code ReUse

You can split your code with different concern :

• Object model extensions
• Technical Infrastructure
• Application code

The first two are good candidates for Code ReUse.

By Object model extensions I’m talking about things that make your code writing less tedious at language level or object model level.

Example of such code are :

• IEnumerable and Enumerable
• Collections
• Reflection helpers
• Dependency Injection framework

By Technical Infrastructure I mean things that make your code run in its environment :

• Generic Service Host,
• ORM, Data Layer
• Format serializers / deserializers
• Configuration helpers
• Communication frameworks (WCF, Service Buses)
• UI frameworks (MVC, WPF)

The last part is Application code, and here, things are really different.

Application Code ReUse

For long I’ve been writing business code in libraries. I began then to notice problems concerning code and data locality.

When you have a single application (process), no problem.

But if two applications need to modify the same entities, the solution would be to use the same library in both applications so that there is no code duplication. It seems good practice but you quickly stumble on several problems – I’m sure you already experienced it :

• Synchronization : the same data will be accessed in the same db from two application, how do you manage conflicts
• Deployment : when you fix bugs or add features, you must redeploy every application that has a dependency on the library. It slows down the release cycle and make it more risky, changes have more impact.
• Code locality : when a problem arises, you have to find which application it comes from.

Let’s examine DDD patterns to see how they fit with reuse :

Services

Let’s start easy. Services are stateless, they should deliver simple action. But to preserve encapsulation the better is to put services as true services in their own process (web service, windows service, service on a service bus..).

This way, synchronization is managed in process, deployment is a breeze, and no problem with code locality – code executes in one place.

Entities

Entities are retrieved through a Repository Service, hence, they should follow the same rules as Services.

This way, the implementation of a repository that access the database is truly an implementation details. Anyone who wants to talk to an entity sends a command to it, a handler service get the entity from the repository, and pass the command to the entity. The configuration to access the database is local the to the process.

Here again, same benefits.

Moreover entities should always have different meanings in different bounded contexts, the should have different implementations, so there is no real reason for reuse.

Value Objects

Value objects are a bit different.

Some object are very specific to a bounded context and don’t need to be reuse outside.

Some other can be a good way to encapsulate some shared concepts. Money is usually a good example, but there can also be concepts more specific to the domain (you will find them as words that come in the Ubiquitous Language of different Bounded Contexts).

They can be shared among different contexts, but rarely between different domains. There are exceptions for very very generic concept like money, but even money often needs to be tweaked a bit for each domain…

Service Bus to the rescue

Once each bounded context is split, you need to organize communications between parts. Here comes the Service Bus and Messages, but now, the only shared parts in the application are :

• Object model extensions (to code faster and cleaner)
• Technical infrastructure (so that each process is fully equipped, and there’s not much technical fuss in the application code)
• General use Value Objects (to manipulate domain concepts instead of int and decimal)
• Messages (to communicate between contexts)

You could also use web services, but it makes the overall structure less fault tolerant, harder to deploy, and more tightly coupled.

Once you’ve decoupled bounded context using messages, the rest is just an internal implementation detail, why would you want to reuse it !

During Evans’ talk at ParisJug, some attendees where surprised that there was no mention of Entities or Repositories…

Quite a lot of people where introduced to Domain Driven Design by these aspects and see these as the main advance of DDD.

In contrast, Eric Evans explained to me he had some regrets he placed these patterns so early in the book. Many readers think they know the most important at this point and stop reading after chapter 6.

Actually those patterns are only object model patterns that enable Separation of Concerns and Persistence Ignorance, but can also be used in context that are not Domain Driven at all like CRUD.

Of course, if you want to implement a domain independent of all infrastructure concerns, good OO practices will be required, but those practices won’t make your application Domain Driven (don’t understand that not following DDD would make your design a bad design… you apply DDD if you want and if you need to, but achieving persistence ignorance won’t mean you practice DDD.)

But you’ve more to learn from Strategic Design, Bounded Contexts and distillation of the Core Domain etc.

Those who already read the book should already know this. It’s still interesting for newcomers and you can  send comments if you want !

During his Talk at ParisJug, Eric Evans presented two possible models for Cargo itinerary.

The first one was around the notion of Stops (at a Stop, you unload, then you load), and the second one was around the notion of Legs(you load at the start of a Leg, and unload at the end). An itinerary could be seen as a list of stops or a list of legs.

The question was, which model is best ?

Of course, there is no answer to this question.

The same question was translated to a comparison of maps. First an map of China from the 16th century, and a Mercator projection map.

We should be inclined to say that the second one is best. But the first one was largely enough for the need at that time. And if you inspect the Mercator projection, you can notice that it is not that accurate for some tasks. For example, the Greenland seems abnormally large.

Why do we use Mercator projection then ?

It became the standard map projection for nautical purposes because of its ability to represent lines of constant course, known as rhumb lines or loxodromes, as straight segments.

If you want a map to compare country areas, use a Gall-Petters projection or a  Goode homolosine projection…

So the question becomes :

Which model is more useful ?

And for the question to be complete :

Which model is more useful for what ?

To come back to the cargo application, Stops will be useful to produce orders to unload and reload containers from cargos, but legs will be useful if you need to track transport location or change routing during transport.

You’ll have noticed :

It depends on the context

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.

While testing NServiceBus and MassTransit – yes I need a service bus framework for my current project – I’ve seen that both library where relying on an IOC container, in two different ways.

Warning: This article is not to flame these two frameworks that seems of great quality. There are still few guidance on using IOC containers in libraries. This is the topic of this post.

The NServiceBus way

NServiceBus relies on Spring or Castle Windsor.

You can notice it when instantiating the Bus :

var bus = NServiceBus.Configure.With()
                .SpringBuilder() // or .CastleWindsorBuilder()
                .MsmqSubscriptionStorage()
                .XmlSerializer()
                .MsmqTransport()
                    .IsTransactional(true)
                    .PurgeOnStartup(false)
                .UnicastBus()
                    .ImpersonateSender(false)
                .CreateBus()
                .Start();

And when looking at the library with Reflector :

and

Yes, the Spring framework and the Castle.Windsor are ILMerged in the NServiceBus assembly.

NServiceBus abstracts the container with the NServiceBus.ObjectBuilder.IBuilder interface :

public interface IBuilder
{
    // Methods
    T Build<T>();
    object Build(Type typeToBuild);
    IEnumerable<T> BuildAll<T>();
    IEnumerable<object> BuildAll(Type typeToBuild);
    void BuildAndDispatch(Type typeToBuild, Action<object> action);
}

The MassTransit way

MassTransit adopts a slightly different strategy.

The base is still the same.

It uses the CommonServiceLocator to have a ‘standard’ interface to hide the actual IOC container implementation.

It provides implementations for the most common IOC frameworks (Castle.Windsor, NInject, StructureMap and Unity – but it doesn’t work so well…) through additional dlls.

The big difference is in the library configuration. You configure the container (through code or configuration). Then encapsulate the container in a Common Service Locator implementation that acts as an adapter. Finally give it to the library.

What’s the problem

In both case, the intent is good, but hell is paved with good intentions.

In Mass Transit, the design is clearly made so that you can choose your container and integrate the library seamlessly with it. You can manage the configuration in your container the way you do it in your application.

But wait ! What if I don’t need an IOC container in my application ?

The other problem is that Mass Transit relies on some advanced IOC capabilities like contextual configuration. The object instantiated for IEndPoint should not be the same depending on the parent object. This scenario is not handled by Unity for instance.

Maybe Unity is not good enough, but how can I know which other specific feature Mass Transit relies on ? No clue.

And providing a library configuration through a container doesn’t seem a best practice to me. The API gives no clues of what I should provide to the library in order to run it.

The only way to know is to launch it, see where it throws an unresolved dependency exception, add the dependency and retry !

And I’ll probably never know about optional dependencies.

On the other side, NServiceBus works with a NServiceBus specific configuration (code and app.config) that indicates  clearly what I must provide to the library.

But Jak Charlton had a serious problem with NServiceBus. He’s not using the same version of Castle.Windsor that the one merged in the NSB assembly ! And the assembly load fails.

What’s the solution then ?

I clearly prefer the specific configuration scheme of NServiceBus, but how can we solve the version problem ?

I will answer with another question :

Why does NServiceBus need two IOC container implementations ?

For library creators, I will propose this way to go :

• Choose the container that provides the features you need
• Use it in your infrastructure
• Create a clear configuration model that exposes the required and optional dependencies that should be provided by the library user
• Consider creating a app.config specific configuration (there are good tools in the framework for that)
• ILMerge your container framework as internal in your assembly.

The alternative to ILMerge is to fork your framework (if it’s open source) and put it as internal directly in your code.

The advantages

• No conflict with potential other versions of the container framework
• A clear discoverable configuration
• No need to use a IOC container to use the library.

What if the container needs to inject dependencies in the user objects ?

Both NServiceBus and MassTransit instantiate user’s objects on the fly.

How can the user add it’s own dependencies if he has no access to the container ?

Let’s step back a little and consider what we would do if there was no container…

• We would use Activator.CreateInstance to create the object.
• Then we would consider it would not let the library user enough options, so we would propose a hook so that the user can manage the instantiation himself. It could be a callback or an interface.

When instantiating user objects with the internal framework IOC container, you remove to your users the right to manage the instantiation themselves.

So come back to this good practice. If the user wants to use a IOC container to instantiate his objects with dependencies, let him do this his own way. And his container will not be loaded with all the framework internal dependencies, this will avoid other conflicts.

Conclusion

Hide your IOC container framework inside your library, it’s a private implementation detail of your framework and we don’t wanna know !

Choose the framework you like, hide it so that it cannot conflict with the one I want to use and we will be friends !

It surely advocates for frameworks with a small footprint, but once again, it’s a private detail.

Continued on IOC Container, Go Hide (part 2)

I was looking yesterday at Eric Evans’ talk at the Øredev conference last November.

You really should see it to understand better one of the most important part of the DDD book that is difficult to grasp on first reading.

I’m currently working on a small company that had a problem with scaling their system. The existing system was working correctly but was going to stall in both performance and evolution perspectives.

When we arrived, the plan of the preceding head of development was :

‘We need to restart from scratch, let’s specify everything, then code a clean version 2.0 in two years, and switch the legacy system off.’

Of course it was expected to fail.

And even if it succeeded, after two years, they would have got the same software that two years before.

It could be cleaner, but who cares ?

When you’ve lost two precious evolution years, for a promising startup, count it as dog years.

When we took control of the situation we planned the following :

• Extract the core business value of the software.
• Spot where you need new features.
• Develop new features as if it was in a clean environment.
• Develop anti corruption layers to hide the legacy system behind clean interfaces.

This way you start to work on new business value now, you make the model cleaner over time, and you have benefits of the working legacy system instantly.

Don’t waste your time recoding what is already working.

Act to add value to your business.This is where your craft should go.

Just have a look to Brad Wilson’s post It's Not TDD, It's Design By Example.

What the name Test Driven Development has going against it is that it doesn’t properly express the purpose of TDD; namely, that it is a process designed to help you drive and iterate the design of your implementation at the unit level.

[…]

Frustrated by the misunderstanding of the purpose of TDD, my friends and I (Peter, Jim, Brian, Scott, and many others, all agile practitioners and coaches) decided to start calling it Test Driven Design. A small change, but it starts to focus on the fact that the process is about design. Unfortunately, that “test” word baggage is still in there, so our next iteration was then Example Driven Design. This worked well too, but “EDD” and “TDD” were still too close together and confusing.

The final iteration ended up being Design By Example (DbE). Now when I talk about TDD, I always call it Design By Example, and explain why we like this name better than TDD. Where TDD(esign) or EDD failed to get traction, people really seem to resonate to Design By Example.

I think we can all gain clarity by using Design by Example instead on TDD. I adopt it from now on.

We still have to find disambiguation for highly overloaded terms like Service and Repository… 

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.

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 !