These are some notes that I took from a presentation made by Gojko Adzic at DDD eXchange 2010. This is a talk about how TDD, DDD and BDD complement each other in many aspects and how these conceps were applied together on previous projects that he was involved in.

An obvious commonality is between TDD and BDD that, they both focus on automating the control over the software project in order to reduce the cost of finding where the problems are. There is another commonality between DDD & TDD, which is they both use experimentation as a means for iteratively improving the domain model or the units under test. DDD plays around with models for finding the optimum and unit tests play around with the code, which has no actual implementors. Additionally, DDD & BDD share the aspects of collaborative development with a focus on the business. DDD demands us to collaboratively build the model with business and BDD takes this further by demanding collaboration with stake holders in defining requirements. By this way, business users can affect the development team and clarify the targets for them. Furthermore, with collaborative specifications, BDD can help the development team to cut scope, in order to meet requirements. Domain experts are not authorised to make decisions about scope.

DDD has the Core Domain concept which is about defining the parts of the model that brings business value. However if there are not enough details for measuring the business value, BDD allows to bring more details to the business aspects of the project with concepts such as Feature Injection [1] and value chains. With feature injections, we pull requirements into project incrementally, and these requirements change the amount of work, therefore the amount of time that we will take into account. Consequently, when alternative models or reference models are being considered for the model to be implemented, we don’t need to consider very long term specifications that are likely to change. We can focus on the time period, that is determined by the requirements pulled in for that iteration.

Design and development techniques complementing each other. Image taken from the presentation by Gojko Adzic

Ubiquitous Language concept of DDD ensures language consistency among team members, however as the project evolves, the terms of the ubiquitous language might gain different meanings for members of the team. Specification workshops can be used as a means of evolving the language. This can be done by using the terms of the ubiquitous language in the acceptance tests that are produced as a result of the specification workshops.

BDD can be very helpful for providing only enough level of detail to domain experts. It gives a higher level of understanding that might prevent exposing the domain experts to technical details that might not be necessary for them. These details should be the concern of the development team and they should be dealt with unit tests.

Domain experts do not need to know low level details of a software project. Acceptance tests used in BDD make it easier for business to understand

Gojko argued that depending on Emergent Design causes inconsistency in large teams, as not everybody is aware of how other members see the system and which approaches they prefer for refactoring.
DDD building block patterns (Entity, Value Object, Aggregate, Repository, etc.) comes in handy in these situations since it allows forming a common language of good practices. This reduces the amount of inconsistency that might be introduced by emergent design.
Gojko said that he doesn’t agree with the view that sees unit tests as something that keeps the system integrated during refactoring, because the unit tests that we have are tightly coupled with a particular design. When the design changes, all unit tests related to that class should be updated. BDD can help during refactoring by providing an invariant that specifies the functionality that should not change. I consider the fact that unit tests (and integration tests) break after changes are made in classes, as a helper for developers to put the system back into work, by pointing the locations where reviews and immediate updates are necessary, which would take much more time if the help of unit/integrarion tests were not available. The important point here is that, during these reviews and updates, business specifications should be used as a reference point for things that should not be altered.

During emergent design, there are times when the design should be captured (i.e. documented in a dynamical way) therefore a reference point for a common understanding of the system can be kept and newcomers to the project can be adopted easily. However the code itself is very low level for this purpose and UML diagrams get old very quickly and it can be costly to maintain them. If the model is reflected through acceptence tests and our tests are automated, we can use this as a Live Specification that explain the dynamics in the model.

During refactoring, it is common to have cases where some refactorings make cross-cutting changes in the system, causing conflicts in the code base. One might wish to have multiple contexts and make refactorings limited to only those relevant contexts, but avoiding cross-cuttings completely can be an unrealistic preference at many times. DDD brings the Bounded Context concept which advocates forming of boundaries for models and enabling communication among these context by making use of cooperation patterns, context mapping, change management protocols, so that the negative effects of refactoring that might be caused by cross-cutting concerns can be minimised.

As a result of these thoughts and as a summary, the following recipe for success was suggested by Gojko:
* Use strategic design to decide what to build
* Use feature injection for adjusting the scope for DDD
* Evolve and maintain a ubiquitous language with specification workshops
* Start with working on higher level domain design guided by business specifications, and establish guidelines
* Then start working on technical details with TDD
* Use context mapping for managing cross-cutting concerns

[1] Elizabeth Keogh, ‘Pulling Power: A New Software Lifespan’,

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>