The Big Ball of Mud
I have always felt that a lot of business software development misses a very important part: a structured and formal approach to the business rules and requirements of the developed system (the business Domain). I have always felt that there was never really a home for it, or at least I was not sure where it should go; front-end developers tend to mix it with interface concerns, database experts tend to put it in the database, and newcomers have no idea where to put it. As more requirements and features are added to the same code base over time, what we end up with is an unmanageable and confusing mess, often referred to as a big ball of mud.
This approach to software development will introduce errors because it is difficult or impossible to properly test. It degrades developer productivity because bugs are very hard to pin down even when their results can be observed, because it is not obvious where to look. Any added functionality will create an even bigger ball of mud as there is no incentive to not do so. Eventually the software solution becomes unmanageable.
So where should these business rules go?
Where appropriate, we follow a Domain Driven Design approach. The Domain components of the solution model the processes and requirements of the actual real-world business processes and requirements. This is done in focused and specific modules that relate to a particular business context – in this way, each module focuses on a specific aspect of the overall solution and does not try and do too much.
These models contain both properties – the current state of the model, and methods – the ability to change the model state through actions. The state of the model should not be externally editable except through these methods and should never become invalid – if an attempt is made to change the model into an invalid state (through a method) that change should fail with the reason. In this way we enforce the business rules of the application.
This works well, and I believe this is especially important for business software, as, often, the requirements will contain lots of complicated business logic, rules and invariants and perhaps state-mandated regulations like GDPR. By attempting to distil this into a single, well-defined layer of the application, it becomes easier to test, easier to maintain and much easier to reason about. Additionally, because the domain model components resist becoming invalid, it should be much more robust and more difficult to break (either intentionally or by accident).
We can then build on and out from the domain components, adding database access and external services, and expose the domain to any software systems that require its services.
The Trade-Offs of Discipline
There is no such thing as a free lunch – on the flip side, this highly structured software engineering takes much more discipline and consideration. It also requires belief and confidence in the process from all involved and therefore can increase the time and effort it takes to initially deliver the system.
