Mark Needham

Thoughts on Software Development

DDD: Bounded Contexts

with 8 comments

I’ve been reading Casey Charlton’s excellent series of posts on Domain Driven Design recently and today came across his thoughts about which types of applications Domain Driven Design is suited to.

Towards the end of the post he talks about the fact that there is a lot of excellent ideas in Domain Driven Design even if you don’t have the chance to use all of them.

…there is a wealth of wisdom and experience encapsulated in Domain Driven Design – use what you think applies to your situation, and you will find your software becoming more flexible, more reactive to your audience, and easier to understand – just don’t expect miracles, and beware of over complicating your code for the sake of it – sometimes simpler really is better.

A pattern which I think is applicable in the majority of systems is bounded context – if I remember correctly this isn’t mentioned in InfoQ’s Domain Driven Quickly book but is extensively covered in the big blue book.

To quote the book with regards to what a bounded context is:

The delimited applicability of a particular model. BOUNDING CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently.

This means that a given model which we define is only valid in a specific part of our system. We would then have a layer of mapping between this bounded context and other parts of the system.

I’ve found this to be a really useful pattern to help reduce complexity where our application has integration end points. It makes it significantly easier to understand the code as you don’t need to keep all the context of what terms mean in other systems.

One thing that we discussed in our Domain Driven Design book club last week is that there are actually bounded contexts within the application itself as well as within the system as a whole.

For example if our application has a back-end database then that represents a relational model of the data in our system – that representation doesn’t make sense in other parts of the system and would typically be encapsulated from our code with the help of an ORM – the ORM effectively acting as an anti corruption layer between the database and our domain model.

I think we can also apply this with regards to the model we use on our user interfaces – often the model we display to our users differs from the one that makes sense to the business.

The only disadvantage of creating all these different bounded contexts is that we need to create mapping code between each of them, a job which can be pretty tedious at times.

On the other hand I think the advantages we get from having clearly defined areas where our various models are valid easily outweigh this in most cases.

Be Sociable, Share!

Written by Mark Needham

March 7th, 2009 at 10:03 am

  • Pingback: Arjan`s World » LINKBLOG for March 8, 2009()

  • Pingback: DotNetShoutout()

  • I’m not sure I got your database example. There is, for sure, some anti-corruption mechanism, usually designed as Data Mappers and other POEAA patterns, but this wouldn’t be a different Bounded Context, those are just -guess what?- Layers. Bounded Contexts are “vertical” divisions, Layers are “horizontal”.

    Or maybe I didn’t understand your post at all.

  • Would that also mean that the UI example wouldn’t work either as I would have thought the UI is a different layer to the domain?

    Maybe I’ve used the wrong terminology but it seems as if the concept behind it is quite similar.

  • I think Philip is right – the concept of layers exists in the DDD book (not to hand so don’t have a reference) … and the persistence layer is just that.

    That said, I would say the UI could well be considered a separate BC – one of the aspects of a BC is that it contains all it’s own code, data and logic – in total isolation, both logically and physically, from other BCs

    By that definition, a UI application is a prime candidate for being called a BC … and I have always tended to. Also b that definition the ORM/DB/Peristence stuff is not a BC, as it is in the same codebase as the BC it belongs to – and there will almost certainly be a complete implementation of the persistence mechanism for each BC.

    Hope that makes sense …

    (oh and btw I think Udi Dahan and possibly Greg Young disagree with me calling a UI a BC)

  • Pingback: DDD: Recognising relationships between bounded contexts at Mark Needham()

  • Pingback: Learning through teaching at Mark Needham()

  • Pingback: Getting a better view from the roof of the Bus | YOOT()