In 2003, a software engineer named Eric Evans, who had spent many years guiding large businesses through the process of building software, published a groundbreaking software design book in which he introduced an approach he called domain-driven design. The idea was the result of thinking about what actually led to success in his business projects: fruitful interactions with the client, analysis of the business problems being solved, building teams which thoroughly understood both the business and the software, and the resulting software architecture. The focus of all these components is the business’s ‘domain’ – in other words, its sphere of knowledge or activity.
Today, domain-driven design is used worldwide for complex projects where software is modelling a real-world system or process. ‘It’s completely different to the classic approach to software architecture, where we design with the database at the core and let the requirements of the database drive the way you design the rest of the system,’ says Mark Tolley, a senior consultant in OCC’s Innovation Delivery Team. ‘Instead, we come up with a tool that helps the business drive its function: the focus shifts onto the business logic. We simplify the system by first modelling a small part of the business and then evolve the model by talking extensively to the client about what actually happens and what they need.’
In essence, domain-driven design allows the development of complex systems whose focus is mapping activities, tasks, events and data within a problem domain into the technology artefacts of a solution domain. A vital aspect is collaboration between the domain experts – the people who know the business – and the software architects in order to create a “ubiquitous language” so that everyone involved is discussing a shared knowledge base with shared concepts. ‘Because everyone agrees exactly what the terms being used mean, we can have a more productive conversation and evolve software that reflects our improved understanding until it exactly matches the client’s requirements,’ says Tolley
With business needs at the heart of a hierarchical software structure, the system can both present users with highly intuitive interface screens and respond flexibly to changing client requirements. Maintainability is also excellent: new technology can simply be bolted onto the ‘front end’ without disrupting the business logic.
OCC has recently used domain-driven design to create TRALC3, the latest generation of its modelling tool for thermal stress in National Grid transformers. ‘The TRALC tools were designed some years ago to allow system operators to model scenarios for individual transformers being put under heightened loads. Nowadays, transformers are increasingly sophisticated with more control options and developments like self-triggering cooling mechanisms,’ explains Tolley. ‘By talking to the operators about exactly what information they now require and using domain-driven design, we’ve been able to develop a more flexible application that can answer their more nuanced questions in a very accessible way.’ He adds: ‘That’s the beauty of domain-driven design: we can make the things that matter to our clients easier.’