Any model is provisional and we need to keep challenging them to find their weak spots, Eric Evans stated in his keynote at this year's DDD Exchange conference yesterday in London when walking through and challenging his own fundamental assumptions of Domain-Driven Design, DDD. Eric excludes misassumptions from his analysis, e.g. that OOP is mandatory or that tactical building blocks like repositories have to be used, neither which are real assumptions of DDD.
The primary challenge for many software projects is the complexity of the domain itself
Eric believes that in most projects this is true even though there are exceptions; one example being projects where the models used are really CRUD based and a description of database schemas. But adding business logic as a tangle of conditionals increases the risk of ending up with a monolith and a big ball of mud.
Business and software can collaborate on deep, poorly understood concepts
The culture of business people compared to technical people is often very different and the way organisations are organised usually doesn’t facilitate collaboration. Finding developers that know the domain well may help overcome this. If collaboration doesn’t work a possible alternative Eric describes is rapid prototyping with business people rejecting prototypes and suggesting changes. The most extreme form of this is replacing a whole system but the risk Eric has found in this is that although building an entire system with the same functionality as a legacy system is not that hard, it often leads projects into the legacy replacement trap, the trouble lies in the migration problem when all the quirks in the data has to be migrated into the new model.
The Core Domain is highest business value, so focus there
Eric’s experience is that teams sometimes have a hard time to find the core domain. A consequence is that it then becomes even harder to find collaborators. An alternative for such scenarios might be to develop much faster so that we do everything without a need to focus on parts but Eric doesn’t think that is possible.
A negative reaction Eric have seen when people succeed in creating a good simple model for a complex problem is that it’s not appreciated because other people tend to see only the model and not the complex business reality described by the model.
Aligning implementation with model improves usefulness and delivery speed
Eric uses an automatic gearbox in a car as an example of a good encapsulation. We accept that the implementation, the inside, is very different from the outer presentation. In software this may correspond to two different contexts with the context for the internal part targeting domain specialists. What we really are trying is finding a model that is understandable by the business as well as practical in implementation, and this has always been a premise of DDD.
Technology is not the problem
Expressing the ubiquitous language in code is something Eric often succeeds with but marking context boundaries and managing aggregates is much harder, often he falls back to convention. Despite this he still thinks that software development is better today than ten years ago.
Modelling is deeply linked to talking and language
Eric is not sure this is an absolute requirement but it’s very much his way of doing DDD. Graphical and mathematical models are alternatives but he thinks this is still DDD. An obstacle he has not experienced is people speaking different languages in a project, e.g. English and Swedish, but understands this can be an issue.
Structure (such as DDD patterns and language) helps modellers work
Eric’s view is that some people are natural modellers with a talent for abstractions. That they know DDD is not a requirement but Eric believes they can work more systematically and use a common vocabulary talking to each other to improve their work, although he has no proof of this.
Eric’s ends his presentation with:
With DDD, as with any model, challenging it keeps it healthy. Back to first principles, again and again, so we can adapt. If DDD is sound, we’ll burn away the undergrowth. We’ll come away with a clearer, more distilled understanding. Then we should be able to make it work under obtainable conditions. If DDD can’t hold up to such challenges, then get it out of the way.
Next year’s DDD Exchange is scheduled for 19th June 2015 and registration is open.
