Check out my new course Learn you some Lambda best practice for great good! and learn the best practices for performance, cost, security, resilience, observability and scalability.
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 podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.
Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!
Check out my video 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. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!
Are you working with Serverless and looking for expert training to level-up your skills? Or are you looking for a solid foundation to start from? Look no further, register for my Production-Ready Serverless workshop to learn how to build production-grade Serverless applications!
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 wrong about serverless and vendor lock-in
- You are thinking about serverless costs all wrong
- Just how expensive is the full AWS SDK?
- Many faced threats to Serverless security
- We can do better than percentile latencies
- 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
- Top 10 Serverless framework best practices