New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Article: Domain-Driven Design at the Center of an Evolving Architecture

| by Floyd Marinescu on Jul 29, 2008. Estimated reading time: 1 minute |
Domain driven design can be most readily applied to stable domains in which the key activity is for developers to capture and model what is in users' heads. But it becomes more challenging when the domain itself is in a state of flux and development. This is common in Agile projects, and happens also when the business itself is trying to evolve. In this latest InfoQ article, Mat Wall and Nik Silver explain how they used DDD in the context of a two-year programme of work to rethink and rebuild popular high-traffic news site

Read Domain-Driven Design in an Evolving Architecture

In the article, Mat and Nik how how they ensured the evolving perceptions of our end-users were reflected in the software architecture, and how they implemented that architecture to ensure future changes. They provide details of important project processes and of specific evolutionary steps in the model.Top level headings:
  1. Background to the programme
  2. Starting out with DDD
  3. Processes for DDD in a growing programme
  4. Evolving the domain model
  5. Evolution at the code level
  6. Some final lessons of DDD in an evolving architecture
  7. Appendix: A concrete example

Nik Silver is Head of Software Development at Guardian News & Media. He introduced Agile software development to the company in 2003 and is responsible for software development, front-end development and quality assurance. Nik occasionally writes about Guardian's technical work on, and about wider software issues at his own site,

Matthew Wall is Software Architect at Guardian News & Media, specialising in developing large scale web applications in an Agile environment. His primary concern at the moment is the development of the next generation web platform for He has given various talks on this and related subjects at JAOO, ServerSide, QCon, XTech and OpenTech.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Great DDD article! by Michael Cohen

Wow! This was a great, pragmatic article on DDD. Thanks to Nik and Matthew for writing this.

I would be interested to know if there were any interesting integration issues with legacy systems that had to be dealt with when creating the domain model. I’m also curious how the controllers worked with the domain model in tandem with the Ehcache.

It would be great to see more DDD articles like this from InfoQ :).

I would like to offer a purely technical NET 3.5/Linq/NHibermate transform by Damon Wilder Carr

Is that something if you were credited we could use? Would anyone be interested ( I do realize many readers could do this just as easily as I could).

You hit a sweet spot of 'not to light not to technical' that serves an area we have not prepared any material for (we do very good on the other ends as those are so much easier!)..

You also have that 'immediately recognizable thing' we can all see in people who are facing the same challenges and your comments make you a stand-out as your what we assert a leader in this area must be : No compromise in EITHER technical, communication or abstract design master. It's a tall order to fill. I'd love your specific ideas on how you see this getting easier moving forward and the role DSLs will play (more interestingly the role of different TYPES of DSLs targeted to different groups).

This is just so well done!

I will work up the working example and all the content as well for your review. My email is damon at agilefactor dot com.

Kind Regards,

Damon Wilder Carr

Colour modelling by Hugh Beveridge

Thanks for the article. I am interested to know whether you used colour-modelling techniques to produce your domain model? Judging by the images provided you didn't.

As DDD is becoming more prominent I have yet to come across any DDD material that mentions the powerful colour-modelling techniques and Archetypal Domain Shape (or ADS, also known as the "Domain Neutral Component"). The ADS and colour object archetypes give any object modelling effort a significant head start and boost the quality of the domain model, through better flexibility, decoupling and identification of object responsibilities. The techniques evolved out of work by the gifted object modeller Peter Coad while working with Jeff De Luca and others (and a set of colour post-it notes) on a large project in Singapore in the '90s.

That project also spawned Feature Driven Development. FDD process 1 has always been: Develop an Overall Model, which has in turn built up a lot of best-practice around approaches to modelling workshops (Jeff De Luca's training courses are priceless).

I wonder whether the DDD world will catch up with these best-practice techniques? In my experience once you start using colours there is no turning back.

For those interested, here are some links to more info:

Here's an introduction to colour archetypes

There is a lot of information about domain modelling at the FDD site

PDF versions of the ADS are available on Jeff De Luca's website

Hugh Beveridge

Re: Great DDD article! by Matthew Wall

With regard to your question about legacy systems: has been live on the internet for around 10 years and, until recently, we have had a huge legacy system running in our production environment. The legacy system is very different to the new system. It is implemented in templates, TCL scripts and perl and has no strong domain model. Also, all of our content is stored in the legacy database. The legacy system was difficult to test and maintain, and the problems caused by the lack of a strong model in the system led us towards domain driven design in the new system.

Our approach to the project was one of migration. In each phase we would identify a set of content & functionality in the legacy system that we needed to migrate into the new one. We would create a domain model for this new functionality and migrate the data and functionality from the old stack into the new. This meant that for the most part we could view the new system as a green fields project, the integration between the system was minimal. There were a few interesting cases however, both systems needed to be able to link between each other so we had to introduce the concept of Tag into our legacy system and LegacyArticle into our new system. It was quite simple to join both systems together with simple mapping tables mapping legacy concepts to our new Tags. Also, most of the language used by the business around the legacy system was quite technical and based around the names of database tables, CARTICLE, CARTIFACT etc. This meant that there wasn't much chance of collision between the newly forming domain language and the legacy system. There were a few concepts that existed in both however, for example the concept of a Section. This term was also used in the legacy system but had a different meaning. We got round this potential confusion by simply prefixing any terms that existed in both languages with "Legacy" when referring to the legacy concepts.

You ask an interesting question about controllers and EHcache. I don't really think that core objects like controllers or caching frameworks are domain objects in their own right, they feel more like essential infrastructure objects than objects that are owned by the business. However, domain driven design leaves a footprint across the whole application. The primary entry point into our application is a used requesting a Page. The primary controller that serves this request is the PageController. This feels right, as Page is an aggregate root. The PageController is not a domain object in it's own right, but it's place in the application & it's name are determined by the domain.

Caching is similar. It is simple for us to calculate when any domain entity has been modified by an editor so we place all of our domain objects in a single cache region (called the DomainObjectCacheRegion) and issue appropriate cache clearing messages when entities are modified. The more complex case is repository queries that cannot easily be de-cached, such as "Get me the related content for this particular piece of content". In this case we store each of the queries in their own cache region. Each cache region tends to contain a single type of domain object, such as lists of pages, articles, job information etc. So, while we don't regard the caching framework itself as part of the business domain, the structure of the cache itself is organised around the domain model.

Re: Colour modelling by Matthew Wall

We didn't explicitly use colour modelling techniques when designing our domain model. In fact, we didn't actually use UML. We used a very low tech approach of simple hand-drawn diagrams, file cards and blu-tak. The reason for this is that to us the most important output from any domain modelling session is a shared understanding of the model between both our business representatives and our technical team. Our business representatives are not technical, and while they can now understand the cut down UML syntax that we use in our modelling sessions they don't have the time or headspace to go any further.

We're also not really interested in generating code from our domain model representations. This leads interestingly into the feature driven development question. We don't use feature driven development per se, but the definitions of the processes involved in feature driven development look quite similar to the agile techniques that we use here at We only feed units of fuctionality that add business value into our development iterations. These feel like features to me. We inspect our code and model and refactor it at the start of each iteration in a way similar to that suggested by feature driven development. Because we are always working on small, incremental, cohesive improvements each domain modelling session is small and simple (often quite informal) as the size of the changes are small. We don't find that our lightweight approaches are causing us any problems. It is simple for us all to gain a shared understanding of each iteration of the model. We are able to deliver functionality according to the model, on time and on budget in a way that our business representatives can understand without complicating our modelling process.

Re: I would like to offer a purely technical NET 3.5/Linq/NHibermate transf by Nik Silver

Damon, regards content on InfoQ, you'll need to contact the folks there. I can address your technical questions though...

In terms of complexity for the future, I would predict both a positive and a negative.

The positive is that this programme of work is particularly large effort, and one we all hope we won't have to repeat for a very long time. So there's a positive that the domain model will be much more stable and embedded in people's minds much more. Stability should help make for a less complex working life, and there may be areas where we are able to refactor the domain model, and so make that less complex.

On the other hand I do worry that less intense work on the domain model will lead to an atrophy of rigour. For example, if you're no longer defining aggregate roots so often, will you forget lots of good practices and lessons? I don't know, but I think it's a danger. I'm unsure if the positive will outweight the negative. We'll see.

Regards DSLs, there are two things that approach that.

One is in our automated functional test suite which uses Selenium's Java client driver. This has been of some value, but not as much as we'd have hoped. That's primarily because of the problems inherent in testing a constantly-changing GUI, and also partly (but less so) because in my view Java is too powerful to be used as a DSL -- you can get people doing clever things which others don't understand.

The second is Apache Velocity, which provides a very simple templating language for the front-end developers. It's pitched at pretty much the right level: flexible enough to be useful, but not so flexible enough that you end up doing incomprehensible things. When things do need to be complex then we shift it back into the application code. There are still problems here around lack of tools support (refactoring and code analysis doesn't exist for Velocity in the same way as it does for Java). But that's another story altogether.

Hope that provides some answers.

Re: I would like to offer a purely technical NET 3.5/Linq/NHibermate transf by Damon Wilder Carr

Much appreciate your feedback. Your answers show your deep practical experience base. I do have some concerns that I was not clear in my questions.

You said when describing a DSL:
".... primarily because of the problems inherent in testing a constantly-changing GUI..."

So my comments are about what you do before testing. Your listing a problem I had though mostly solved. For example, we assume as a ‘critical success factor' quite literally the existence of MVP/MVC or other design moving any 'reuse potential' code out of their view implementations.

In fact, this is our first assessment made when working with others. Short of this baseline, we assert forces will drive the solution into very bad places and the goal of everyone (which you cover in this article) would be nearly impossible , at least where you have complex views (say Ajax driven web in one view and mobile apps for another over the same domain).

Are you saying THIS IS NOT a prerequisite in your opinion? We would love your thoughts on alternatives, as this is a tangible pain-point.

See the footnote (1) for our detailed assumptions and practices around this how we (and I know of many others) are supporting this via Continuous Integration with assumed design in place.

Next is your statement:
" my view Java is too powerful to be used as a DSL -- you can get people doing clever things which others don't understand..."

I do not follow. How do you associate this to DSL implementation? Indeed how could any language be 'too powerful' for DSL realization?

In my experience and opinion, you only are limited when faced with languages not powerful enough and if lucky enough to have too much that is nothing new. We have always had under skilled developers going nuts and abusing the power of languages.

<strong>OO Multiple Inheritance / Fragile Base Class for Example...</strong>

Most would agree that C# was not a candidate language for internal DSL creation until the 3.0 release.

As an example, the addition of extension methods allow fluent APIs to evolve even around others's APIs, without source modification (what Fowler is calling ‘Expression Builder' in one part of this, in his upcoming DSL book).

Also C# 3.0 provides another core enabler in Linq for DSLs as now we can manipulate the expression trees at run-time (well we always could but it is just within the grasp now of far more than before knowing it is still non-trivial).

Would you agree that DSLs would meet their true potential when they are fully integrated 'graphical as well as text' in implementation and are fully realized for use outside the development team?

This is the ‘how are we going to be tactical in iteration and discovery yet execute on strategic items not relevant for current iterations.

This has been a core concern of ours since around 2000 as explicit and likely an implicit concern for well before that.

"...I do worry that less intense work on the domain model will lead to (lack of I assume you mean) rigour."

We all walk this high wire.

"...if you're no longer defining aggregate roots so often, will you forget lots of good practices and lessons? I don't know, but I think it's a danger"

Again, this is elaborating the idea above no. Your example is a good one. We must balance the two perspectives and most (many) we have find COMPLETELY overemphasized the arguably much easier aspects of the code and short-term iterations.

Kind Regards,

Damon Wilder Carr

(1) Continuous integration as prerequisite to Agile and Domain-Driven Success

  • Doing this first teaches an organization what to expect

  • If it fails, Agile would of likely been a vastly larger failure

    • The best will learn from failure and keep going

  • Ability for ‘all the time' knowledge of the operational state of your assets

    • Not about ‘does it build' except in early stages, but about ‘does it prove itself as valid' now and for the future assume fundamental change is happening around and within it.

    • Extends TDD with explicit mandates for mock frameworks solving the dependency issues.

  • Your MVC/MVP work allows associated service layers to participate in the above

  • Although many have solutions that do some of the above, we have not found a reasonable solution for true ‘regressions without mocks driving real view implementation on the C.I. server'.

  • We must offer transparency and no barriers to understanding the work at the level anyone desires. This is optimized step (option but very value add) of your code as data warehouse/repository for understanding metrics you care about

  • We cannot control the context of execution of the C.I. server so we are driven to add the condition of 'proof driven mocks'

We ask developers to think about how they will prove their code works now and in the future via automated means. Nothing new, but the ‘prove' aspect means they are held to their code only, and their designs but mocks will handle dependencies. This eliminates most arguments against it.

We also expect many metrics from the C.I. server and value added services like build versioning and automatic packaging with archive, alerts with targeted filters to the concerns of an alert receiver (no detailed alerts to the CTO but always to the developers, etc.)

This is a main reason we are effective in fundamental change. We are now operating from facts of our code ecosystem.

Re: I would like to offer a purely technical NET 3.5/Linq/NHibermate transf by Nik Silver

Damon, acceptance criteria are agreed before development starts, but it's a by-product of the Agile process that changes will occur after development starts, including changes to the acceptance criteria. So late front-end changes to occur frequently, as do changes to previously-established features.

On your other point, I agree that Java isn't really a DSL, even if we only use a controlled subset. This is why I described it as one of "two things that approach that". It's not a DSL, but it approaches that. It's too powerful in my opinion because its users (when it's used like a DSL) do not have advanced Java skills, yet it can be refactored and rewritten so that you need some reasonably advanced Java skills to understand it.

Modelling by Neil Murphy

20+ years ago I developed domain models using ERDs with business users, who took to using them like a duck to water. I developed systems with users using RAD methods. Amazing how much is forgotten and then trotted out as something amazingly new.

DSL + Code Generation + CI by Raghavendra Keshavamurthy

The main focus of this exercise seems to have been to get the business users own the domain model and the share a common ubiquitous language between the technical and the business folks. These are good achievements no doubt, but from a development point of view, I think the full power of MDD is realized only when you have a DSL, code generation templates and CI processes to go along with the model. In fact MDD without this does not differ significantly from developing systems using ERD and RAD as mention by Neil Murphy. For example how would you ensure that your domain model and code is in sync? The real goal would be to allow the business users to control not just the domain model but the entire business side of the application as a whole.
Would be interested in your views on this.

Re: DSL + Code Generation + CI by Nik Silver

Raghavendra, we haven't seriously looked at creating a DSL (other than in Velocity) and code generation templates (though we do have a CI pipeline). I think it may be something we look at in the future when we better understand our pain points and opportunities to optimise our work. However, at the stage the work is now, the scope of development is too wide to introduce those kind of things for a particular aspect of the application and to be sure the cost will be outweighed by the benefit.

We don't have a very big problem with (your example) ensuring the domain model and code are in sync. It's a pretty simple relationship, and we have a general understanding that no-one messes with the model layer without an explicit business need backed up by completed analysis. Obviously that kind of implicit social contract can go wrong (as in the example of the FootballMatchSummary) but it's picked up through pair programming and moving developers across the different streams of work which ensures further peer review.

As for business users controlling the entire business side of the domain, I think there are two requirements for that which we don't have today. One is the single authoritative voice of decision-making. As described in Section 3.2.1 the Production team play this role significantly, but there are still a lot of individuals who have a voice. All this is captured by our business analysts, and therefore they are the ones who might be users of the DSL, not the business users directly. Another requirement is business users who have the time to learn and maintain the DSL code. I suspect this responsibility would take editors, production staff, sales people, etc, too far away from their day-to-day jobs.

None of this is saying a DSL, code generation templates, etc, wouldn't be appropriate, only that I think they're not appropriate for the organisational environment as it is today. That environment will change, the balance of our work will change, and people's roles and responsibilities will evolve. The tools you outline are likely to be seriously considered in the near future.

Re: I would like to offer a purely technical NET 3.5/Linq/NHibermate transf by Damon Wilder Carr

I see where your coming from.. Thanks for the feedback. It's much appreciated.


Re: Modelling by Damon Wilder Carr

ERD != Domain Model


Great by Cheung Ryan

Great article, this really help me out to understanding DDD. And thanks for sharing!

Services by Normen Müller

Hi, in section "2.2. Embedding the domain model into the system" right beneath the graphics you state:

The Model layer contains the domain objects and repositories, with services residing in the next layer above.

The "next layer above" is not depicted within the graphics, right? It would be in between "Web Site" and "Digital Content Platform", correct?

Best, /nm

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

15 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and dont miss out on content that matters to you