Developing software is challenging. It's not just writing code. It's everything from discovering a problem, doing process and product analysis, developing requirements, writing code and iterating on the process.
As software engineers, most of us have experienced a “spaghetti” or "big ball of mud" codebase. A codebase with no clarity, where there are dependencies in all directions. This is a symptom of code that is often highly coupled, fragile and difficult to test and maintain. A change to one part of the code may have a big knock-on effect.
There is often a common cause for this - developers are trying to build software solutions with a lack of business knowledge and understanding. When this happens we end up with software that does not truly represent business functionality. A traditional waterfall approach to developing software can be a root cause of this because it focuses on one person or team gathering information and requirements, then passing to engineers to build and deliver. There's a huge gap of knowledge transfer and collaboration.
Domain-driven design approaches software development with a focus on engineering teams gaining a rich understanding of business rules and processes from domain experts. It involves engineers being involved early on in the discovery phase and working closely with the product teams and domain experts directly. The aim is to understand as much about the domain and the business as possible. This has many positive impacts.
- It provides context
- It aligns the engineering team with the business
- It reduces ambiguity and information lost in transit
- It helps to improve communication because a common language can be established
- It facilitates changes because everyone's on the same page
- It decreases complexity of inherently complex problems
Although there are technical patterns engineers can use when writing code, it’s important to remember that domain-driven design is not just about code. It is not purely a technical concern. It is a wider concept that can be utilised by other team members including product teams and key project stakeholders. It requires engineering teams to seek understanding of the problem space before trying to solve the problem, and modelling the domain using that understanding. It involves establishing a common ubiquitous language that improves communication and helps to create software solutions that are clearly aligned to business processes.
If we align the software we build to the business we can write better, more easily maintainable and testable software. We can also communicate more effectively, thus enabling us to tackle software complexities when solving complex problems.
