Explained | Domain Driven Design
Are you sure you’ve planned out the structure of your new app?
In most cases application code will begin to grow in complexity, and with that the inability to keep control of the business logic within.
Structured programming is the aim of improving the clarity, quality and future development time of your application by applying known design patterns. A well-known design pattern is called Domain-Driven Design.
What is the Domain?
The domain is a targeted subject area of a computer program.
A common term for this in software development is the domain layer / logic, also known as the business logic.
What is Domain-Driven Design?
The concept that the structure of your application code, such as the class names, methods and variables you create, should all match that of the business domain.
DDD is a design that is built around a model of a real-world system. In essence, your design best interprets that of what a domain expert visualises the a real-world system, split into its individual components. For example, if you was to create an application that simulates that of a shop, your domain expert would be an experienced shop owner.
The design should allow for you to show the process to a domain expert and for them to verify the business logic is correct. For instance, using correct names for entities such as Orders, Products, Customers etc.
Structuring your domain into sections
In order to achieve this design, it is useful to note the different sections:
Entity: A domain object is usually used to establish a mapping between a domain object and a table in the database. The columns of a database table can be transformed into the attributes of an entity. Entities have a unique identity (ID) although their attributes can change over time. Examples of this would be a User, Product, Income, Account, Dog and Cat.
Aggregate: A collection of entities as described above, such as a group of users.
Repository: A layer between the domain and data layers of your application with an interface to perform create, read, update and delete operations when interacting with the database. For example, requesting all products in the database which are then converted into collection of domain objects in our domain layer.
Service: The performing of a set task (e.g. calculating a loan, updating a user) using the information provided, using any repositories or other classes you have created outside of the service.
Factory: A creational pattern which handles the creation of new entities and value objects.
If you would like a further understanding of the repository or service pattern, please check out my other article which looks into them in more detail.
In addition to the factory method pattern, there are many other design patterns that can be applied to your application. If you would like to look further into design patterns, I would best recommend refactoring guru.
The benefit of applying the above is that you have sectioned your application into managable building blocks, where each section serves it’s own purpose. The example below shows a product entity in an e-commerce app with the structure described above.
By sticking to this design pattern, we can create a collection of modules for our app as shown below.
Conclusion
In summary, Data-Driven Design is a comprehensive approach for solving business problems and structuring an application correctly to make it easier for future changes to your code. It isn’t a universal solution for all projects, but it can be a great choice for new projects when the initial structure of the app is uncertain. It is also heavily based on Object-Oriented design, allowing for easy alteration and debugging in future changes.
Be sure to give claps if you found this article useful!
