Domain Driven Design (DDD) is an approach to software design which puts the focus on the problem domain and provides a structure for making design decisions to accelerates software development for complicated domains. The key components in DDD include:
Domain: the subject area to which your program is applied
Model: abstractions that describe aspects of a domain and can be used to solve problems related to that domain
Domain Experts: people with the most complete knowledge about the world your system will live in
Ubiquitous language: a language around the domain model used by all team members, the language is ubiquitous because it is present everywhere
Traditionally .Net applications are developed using a data-centric approach where you build your system around your understanding of the data – creating all the tables and the relationships in the Database and then mirror them in your .Net code. This approach is popular because of the ease and speed with which you can create a fully functional system from the ground up.
DDD on the other hand, focuses on the problem domain as a whole which covers not only the data but also the behaviour. DDD encourages greater involvement from domain experts, the idea is to build your system in a manner that’s reflective of the actual problem domain you are trying to solve and let the domain drive your design decisions.
One of the greatest challenges in developing a new system is to learn and understand the new business, which is why a single, shared language (the ubiquitous language) between the users and the developers can go a long way to reduce misinterpretations and create a more concise and effective communication amongst all interested parties.
It is important to remember that whilst DDD is better than the data-centric approach in some cases, the reverse is also true.
Also, DDD carries with it the overhead on the developers’ part to become proficient (or sometimes experts!) in the problem domain and being able to communicate with the users in an common language.
Mastering both programming skills and business knowledge in the core problem domain is difficult and takes significantly longer than the course of developing an application – seasoned developers in the Financial sector would no doubt agree with this! This is one of the reasons why knowledge in a particular area (equities, derivatives, etc.) is such a valuable asset and developers who also qualify as domain experts in a business area are so highly sought after and compensated.
On the hand, it is also why so many find it hard to break into Finance despite boasting impressive development skills, and why many others become typecast with a specific industry/area and find opportunities outside their familiar territories hard to come by.
During my time with Credit Suisse I have come across many developers who have spent their entire professional career in the same business area, becoming domain experts in their own right. Though personally it’s not what I’m looking to get out of my career I can definitely see the merits of doing so and appreciate the enthusiasm they have for their problem domains.
I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
Check out my new course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, callbacks, nested workflows, design patterns and best practices.
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong