DDD and DDD Light
Domain Driven Design (DDD) and
Domain Driven Design Light (DDDL) - are the set of the best
solutions of many architects and developers, who faced the same problems due to the growth of
The main goal of
DDD Light is to reduce the complexity of modifying existing and
introducing new functionality with the growth of the application.
Difference between DDD Light and DDD
DDD Light (DDDL) removes many of the concepts of standard
DDD in favor of speed of development
and faster entry of new team members (both developers and managers) into the process, which
allows you to use it even when writing MVPs.
To be even more precise,
DDDL is a set of plug & play concepts. Choose exactly those that you
like and learn to apply different concepts for different tasks.
There are two components: (1)
Design and (2)
The main idea of the
DDD approach is the ability to quickly “penetrate” into the context of a
business, communicate effectively and solve business problems.
We will definitely touch upon the topic of analyzing the project and creating very cool and understandable documentation that will be incredibly useful for managers and developers. And when I speak of documentation, I mean both text and video materials.
Design patterns and methodologies:
Repository + Query Object + ORM- as ways to organize access to data sources (databases, third-party APIs, fs and the like)
Aggregate + Rich Domain Model- as a way to organize Application Entities and business logic
Domain Features- as a way to highlight business logic in the context of several Entities
Application Service- as a convenient way to organize Application logic
Service Object- to maximize SOLID in Domain and Application logic
Latent CQRS- as the rules of what the API can or can’t do, and also what kind of operations can be performed inside the endpoint
Minimal AOP- as a convenient way to “slice” logic and reuse it
Backend for Frontend (BFF)- as a way to aggregate data for the frontend and make the frontend more and more “stupid” and the backend more “smart”
Domain and Intergratione Events- to implement asynchronous operations and reduce logic connectivity (and also Saga, but more on that later)
Behavior UniT Test Driven Development (BUTTDD)- everybody love butts, but nobody love write tests, but this is an approach combines the best from both worlds so you will love writing tests.
When DDDL is needed
There are 2 main situations for using DDDL: (1)
Enterprise and (2)
When you are already big enough (or you absolutely sure will become) and you need to solve scaling problems.
DDDL is a set of plug & play concepts. Choose those that you like and use for health.
- If you have many data sources (databases, third-party services such as Auth0, Firebase
, Hasura, partner APIs and so on)?
Repository + Query Objectwill help you.
- A sea of complex queries litter your code base? - again take a
Repositoryand get a
Query Objectfor free!
- If you have a lot of input APIs (user, admin and a bunch of other REST APIs, bots, GQL) - you
need a magic of
BFF + Service Object
- Tired of a bunch of “pass-through” logic litter the code of operations: validation
, authorization, logging, transactions, tracing, metrics, .etc? Then you need
- Tired of the mishmash inside the application: a change in one
place breaks everything else, new developers piss and cry when they see the code - then it’s
time to find out what
Application and Domain logic, Aggregate and Rich Domain Modelare
- Okay, we pushed everything into the services application logic and domain logic, but the
application services are simply fat! Then we turn towards
- Has it become difficult to write data queries? It is unclear how to mix this with business
logic models. -
CQRSto the rescue
- Does the API behave unpredictably? - again
CQRSto the rescue
- Already not fit in CRUD? - again
- To write tests for the endpoint API, you need to raise the HTTP server, database, fixtures
, Redis, beat your wife, deploy sandbox of third-party services, in short, is it impossible to
write unit tests? God help you… And also
- Too long chains of operations, in which a lot of calls to third-party services
Integration and Domain Eventswill help bring this logic away.
I know it seems complicated. But a close look will notice a branched tree of problems and solutions. If you can predict some branch of this tree at the start of the project, then you can immediately lay down these concepts. If not, then wait for the rupture of the anus and begin to enter them after.
From the very beginning of any long-term average size project in any language and framework, I would always use:
BUTTDD + Service Objects + Rich Domain Model + BFF + Repository + Query Object
The rest is optional.
Situation: our client asks to develop a service that will go for data in DynamoDB and transfer it to Firestore, so that the client application displays them in real-time , and from Firestore denormalize and put it back into DynamoDB. And since the load is very large and you need speed indefinite scaling, you need to use the serverless architecture on AWS Lambda.
And I’m afraid that no MVC Framework is suited for such task.
Ok, write without MVC. But how then to structure the logic? Beat layers, make data requests and then process them?
DDD Light helps you easily work with projects that require maximum flexibility.
And these principles apply to any language and field of development: from frontend to backend, from CRM development to cryptocurrencies and IoT.
Therefore, recognizing them once - you become a cyberwarrior, capable of writing cool software anytime, anywhere.
When DDDL is NOT worth using
Firstly, if you have a project that just needs to be done and quickly: an API in a week, an online
store in a month, an internal project in a couple of days - then you do not need
Secondly, break your software into modules, and use
DDDL only where it is needed:
- Need authentication? Use Auth0, Cognito, Ory
- Need content management for a system / application? Uncover some (Headless) CMS.
- Need an admin? We reveal Django / RoR / Laravel + October CMS / AdminBro / React Admin / Retool / Directus
- Need CRUD / Real-time? Then Firebase, Hasura or some kind of automatic generation library (like FeathersJS) is at your service.
- Do you need a module that will combine all this and turn all this mess into a specific product
(for example, a distance learning platform)? That is the best place to use
As you can see, the appropriate usage of technologies allows achieving the maximum result from each of them.
In the next step, I’ll release the Table of Contents and begin to talk about Entity, UseCase, and Aggregate from DDD.
News on the release of articles, wait on the Tg channel @davidshekunts_blog
See you in July 2020!