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

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

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

blog.domaindotnet.com

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

With regard to your question about legacy systems:

guardian.co.uk 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.

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 guardian.co.uk. 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.

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.

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

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

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

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.

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.

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.

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.

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

Damon

ERD != Domain Model

Damon

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

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.