It was fun in the beginning, wasn't it?
Customer after customer, feature after feature. Here we change this, here we change that, here we add 2 fields, here we add 3.
All according to plan.
And suddenly it starts happening again.
Adding 82nd field to the Products table results in significant performance issues for the application. Adding a business rule involves rewriting a few places. Fixing the bug causes several others to appear. New team members require 3 months to be productive. Maintenance costs begin to rise exponentially.
Ooops. Here we go again.
What if I told you that all this could have been avoided? With the help of Strategic Domain-Driven Design. It can support us in the beginning of the project or while refactoring the legacy application. Thanks to it, we start thinking about our business problems and not technical solutions. Because of it, our applications retain a longer expiry date - it is way easier to replace technology, framework or a library than to notice that our business processes were modelled incorrectly.
That's where DDD shines.
The Scope:
- Analyse business domain using Event Storming
- Split to subdomains
- Define types for each subdomain
- Define bounded contexts around subdomains
- Define architectural and logical patterns
- Deep dive into context map
- Ways to transfer the design to solution architecture
Benefits:
- Reduced number of performance issues
- Reduced onboarding time
- Reduced maintenance costs
- Longevity of application
- Ability to deal with change and decision making
