DDD Introduction
As a Developer or Software Engineer, you're probably working with teams of varying skill, size, and expertise. Usually in an environment where people can be slotted in and out on a weekly basis. Or maybe you're a consultant or freelancer who has multiple projects in different stages of development.
Keeping track of every project is a daunting task. You don't need the application organization and structure to add to that mental load.
Reactium aims to lighten the load by implementing Domain Driven Design (DDD)
Domain Driven Design
A common strategy for developing applications is Model Driven Engineering (MDE), where the code is organized by functional domains. A popular MDE is Model/View/Controller (MVC).
Techs love acronyms
In most applications that follow MDE you'll find that creating the initial feature is pretty straight forward.
Need a view? Just add it to the /views directory and give it a name-spaced file name.
Need a controller? Just add it to the /controllers directory and give it a name-spaced file name.
Before you know it you have a completed app where there are 50 views and 50 controllers. Doesn't sound too bad. But what happens when your application model spans more than just views and controllers? Given the feature of a Page, your model could expand to include styles, services, assets, and lang.
Fast-forward 2 months. The marketing department has asked for a new hero image on the Home page with a Spanish and Chinese translation with right to left design implemented for the Chinese translation.
Looking at MDE there will be a fair amount of traversing and getting your bearings on where to make the necessary edits (even with the fixed set we're working with in the following example).
Imagine what MDE would look like if you're looking at a full site with multiple page templates and multiple language support.
Looking at DDD it's a lot easier to figure out where to start and what to touch.
You'll notice that since we're working with an exact set of files in each domain, we can reduce the number of sub-directories required for grouping files, opting to only use a sub-directory when the number of files will be unknown or varies per domain. You'll also notice that the domain model for each page it the exact same, creating an implied knowledge of the codebase and establishing predictability.
Imagine the same request came in for the About page.
After completing the Home page edits, it will be easier and faster to make the About page edits. Your brain has the domain in recent memory and since the domain model is the same, you spend no time traversing the code for the necessary files to edit.
DDD Pros
If you were new to the codebase, you wouldn't have the entire application to discern while trying to figure out what to edit. After successfully making the first edit, you will feel empowered to make the next and any other similar changes while increasing your domain knowledge.
Domain experts can write clear and concise documentation that can be consumed in smaller chunks with progressive knowledge acquisition making the on-boarding process smoother and require less hand holding.
Creating variance is as easy as replicating a domain and making the necessary changes.
Installing, removing or refactoring a feature is simple and less risky.
Identifying problems is a tighter loop as most issues will be domain specific and not systematic.
Identifying systematic issues is easier, you'll be able to trace where the issues are based on which domains are effected and what they share in common.
It wouldn't be fair to suggest DDD without listing its cons.
DDD Cons
Repetitive. With having a domain model comes the need for boilerplate code. This can be mitigated with generators and aggregators.
Maintaining the domain model integrity will some times cause for micro-files with 3 or 4 lines of code. It's worth noting this is dependent on how you structure your domain model. The more specific your domain files are the more this will happen. With practice you can find your sweet spot pretty quickly.
Refactoring boilerplate files can become tedious. With a good IDE this isn't as big of a problem. You can easily enough do a regular expression search in a text editor like Atom and aggregate the files into a list much like they would be shown in MDE.
Sharing functionality across domains can be risky if not done with care.
Neutral: With larger or remote teams, planned collaboration is needed to ensure domain experts can share knowledge and reduce duplicating effort when features have overlapping requirements. This can be both a pro and con depending on your team and how you prefer to work.
Last updated