As an introduction to this series of post on solution architecture, I have outlined the key principles and patterns that I use to design and architect real world applications.
Domain Driven Design
Domain driven design is a collection of principles and patterns based on two premises: that complex designs should be based on a model and that the primary focus should be on the domain and domain logic rather than the technology used to implement the system.
The basic tenets of domain driven design are ubiquitous language, bounded contexts, principle of single responsibility and principle of least knowledge.
These principles are a subset of the classic OOD design concepts expounded to solve poor dependency management that leads to code that is hard to change, fragile, and non-reusable.
Ubiquitous Language
Domain experts use company or industry standard terminology. In domain driven design, this vocabulary is referred to as Ubiquitous Language. It is used consciously and as a disciplined rule throughout the solution architecture and database design to reduce the mismatch between business and technological language helping to deliver business value.
The language can be further refined into naming conventions that are clear, concise, descriptive, and imply intent, form, and function to design discoverability and maintainability at the heart of the project.
Bounded Contexts
A bounded context is an area of the solution architecture which has explicitly defined borders, has its own model and maintains its own code. Each bounded context has a specific responsibility and can operate in a semi-autonomous fashion. The splitting of a large application into many context yields the advantages of modularity, separation of concerns and loose coupling.
Single Responsibility Principle
Entities should have one, and only one, reason to change. This leads to two benefits:
- Increase Separation — Breaking code into multiple classes improves the readability and maintainability of a system and helps isolate the effect of changes.
- Increase Testability — Dependencies are reduced. This facilitates unit testing and reduces test friction.
Principle of Least Knowledge
This principle is also known as the Law of Demeter. The principle strives to achieve low coupling among objects and reduces the interactions between objects to just a few close friends. The fundamental notion is that a given object assumes as little as possible about the properties and structure of other objects. This leads to software that is more maintainable and adaptable.
Given that change is constant in a software project, this principle provides many benefits when rightfully applied:
- Increase Maintainability — Code is easier to maintain because any change can be isolated to a very limited number of objects. This focus on behaviour of a limited number of objects helps with code that is easier to understand, use and reuse because objects are not tightly related to a web of other objects.
- Increase Service Alignment — Adoption of this design principle allows the evolution of components in the solution architecture as they are not tightly coupled with other components.