The digital age offers opportunities and challenges to businesses. We need to transact, record, engage, suggest, share, control, and perform many more digital activities. There is often a gap between IT and business which serves no one. Aligning your IT capabilities with your business needs becomes easier if you adopt a process like Doman Driven Design (DDD).
KRS, as a bespoke software development house, is successfully applying the principles of DDD to tame the complexity of digital systems. KRS also understands how the lack of good design plagues many teams. This ‘difficult’ code is often hard to maintain and extend, and ultimately ends up being rewritten – in the hopes of a better structured solution.
However, rewriting a system simply exchanges a set of known issues for a set of unknown issues. In short, if the team hasn’t learnt better design and refactoring techniques before they start the rewrite, the new code base is very likely to head into the same quagmire as before.
How does DDD help to address all these issues?
DDD describes a methodology for modelling software according to the fundamental language and behaviour of the business domain. This helps to align the software developers and the written code more closely with the business.
One of the first and most critical stages in DDD is agreeing on the ‘meaning’ of various business terms – do we speak the same language, and do we have the same meaning?
This agreement around naming conventions is referred to as “ubiquitous language” in DDD. It is the first alignment that says that those involved will be consistent and precise in the terms they use. In code terms, this means that in any place in code, data or communications where a term is used, ubiquitous language rules.
Organising and structuring code is necessary to help people understand the code that is produced. The computer will run any old mess, so long as it’s syntactically correct. Unfortunately, human beings often forget this and write intricate, difficult-to-understand code for a variety of (incorrect) reasons.
Sometimes, this occurs because the problem space was not fully understood in the first place. Further complexities arise as the project progresses and by the end, there is what is termed as a ‘Big Ball of Mud’. This is code that’s horrible to follow: poor structure, complex interfaces, long methods that are hard to test etc. It’s also called spaghetti code because everything’s so tangled up.
While this legacy code is difficult to work with and slows down innovation, there is usually a large amount of business value that lies hidden in these old code bases. DDD assists teams to strategically refactor the code, taming and unravelling the spaghetti, prolonging the system’s lifespan.
There is, however, no need to wait for the system to become a big ball of mud before applying sound principles, as DDD supports the Agile process, helping to align software with business needs through a rigorous engineering design approach.
More in-depth design upfront definitely helps to reduce some of the unknowns. But upfront design is a Goldilocks problem. Too much upfront design can become “Analysis Paralysis” and can be out of date by the time we start development in a rapidly changing business environment. Too little leads to errors and missed functionality and generally unhappy users.
Finding the spot where Goldilocks’s porridge is just right, is partially experience and mostly good process. We’re looking for an iterative process with a solid engineering approach. A merge of Agile and a modelling tool like DDD.
DDD is an approach for handling software that is strong on principle but does not dictate implementation – it’s what fits YOUR domain. At the very least, it provides a strong set of guidelines and a methodology to cope with the complexity that is today’s business domain and assists everyone to be on the same page, which can only be of benefit to all.
KRS, with its Systems Thinking and Agile approach, in conjunction with DDD, has the proven ability to help organisations speak the same language and get on the same page.
The question then, does your digital software talk to all its audiences and do all parties understand each other?
This article was published in partnership with KRS.