Clientside development is getting more and more complex, especially with applications that need to interact with multiple domains. The problem in big applications with multiple domains is that it is very easy to add complexity into the growing application. If not careful, it will be unmanageable at some point. In my opinion, we can prevent the problem with good architecture and right structure of the codebase. It is not new to apply Domain driven design (DDD) to clientside, just that there are not many discussions on the topic in the community. We can only find the best solution if more people talk and discuss it. In this post, I will offer my view on how we can apply DDD to structure clientside codebase.
Domain driven design (DDD)
Definition of DDD from Wikipedia
Domain-driven design is the concept that the structure and language of software code should match the business domain.
We can see more details in following example picture:
One prominent application of DDD is in clean architecture which I described in the previous post. Apply DDD correctly, we can gain a lot of benefits in developing applications.
Why do we need DDD for clientside
DDD for clientside
- Domain Component vs Pure UI Component
The name already suggested the idea of
Pure UI component, it is used for small, dumb UI component that can be re-used in many places. Within
Pure UI area, components can be
Element is a single independent component such as: Button, dropdown, icons… while
Layout usually composes many
Elements and put them in the same
Pure UI component is any logic you may have for that UI part e.g. React hooks, setTimeout, debounce logic…
The similar idea is also applied for
Domain Component, it can have
Domain component consists of many
Pure UI components.
Domain Component can be considered as container components that handle all the logic and keep
Element components pure.
- Domain and Feature
Each domain is a bounded context, that contains everything like
Domain Component. In clientside context,
Logic should have all
actions (in case of Redux).
- Application base
For application to work, there are other necessary parts like
Infrastructure, which contains services such as ajax, logging. Everything that needs to boostrap the application. Application may also have
Utilites for helper functions e.g
Organizing code as features helps developers quickly find and remember the location of files, they do not need to jump into many places to edit. This will reduce the mental overhead of memorizing the implementation for the features. Most importantly, all the domain knowledge is kept and maintain easily.
I hope this post can increase your awareness for domain driven design on clientside. Happy coding :)