Domain Driven Design

Eric Evans was a softly spoken American who came over to talk about the strategy we should use when trying to build large systems. Eric Evans is the author of a book called Domain Driven Design which contains a set of ideas that seems to fit well with agile processes. His talk was focused on using his techniques a defined in hisbook.

Eric started out by talking about a company that tried to create a new system out of two old legacy systems. The plan was to spend a year building a platform for the new system, spend a year writing the old code onto the platform and then spend another year creating new stuff. Eric thought that this was a recipe for disaster.

He then went on to define things like domain and model and context, and argued that a model has to serve a particular use and that it does not have to be completely accurate. He followed this by demonstrating that you can come up with an inaccurate model of an elephant, and still come up with something useful that you can use. He then said that each system will have its own model, defined in its own context. Models of similar things will be different in different systems, because these system's contexts are different. You can come up with a context map for your various systems if you agree with this idea.

Eric then advised us to try and find the core part of our domain in our systems, because this is the part of the system that gives the most value to the business. This is the part that gives the business's customers a reason for buying from this company.

Going back to the example, Eric postulated that the core part of the business, was the part that was going to have the changes applied to it in the third year of the old development cycle. If this was true, then this is far too long to wait. The legacy systems would have probably had those changes applied to them and the new system would still be trying to catch up. Eric's solution was to create a little platform that would act as an interface between the two old legacy systems and the new system, and then just build the changes into it. This could probably be achieved in 12-18 months - a much more realistic time scale.

The only hole in this idea would be if you needed to kill a legacy system as soon as possible, because maybe it was costing you a fortune in licensing fees for the hardware or something. This does not kill the idea, though, and we could all see that this new part would be an excellent start point for moving other parts of the domain onto the new system.

And all this at eight o'clock in the evening.