Chapter 4: Data Model
Anatoly Volkhover
Domain-Driven Design helps you create a data model that closely follows the business concepts, and therefore is easy to evolve alongside with the business requirements. Use CQRS to keep your interfaces clean.
Session expired
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.
I recently finished reading this chapter and found it very insightful! I’ve been using Go for the past few years but haven’t seen a good example of DDD, so I tried to implement something close to your Typescript examples in Go: https://github.com/tizz98/ddd the main challenge was that Go doesn’t have generics. In Chapter 2 you discussed the importance of choosing a programming language, would you consider generics an important piece?
Hi Elijah,
Apologies for the delay in responding. Glad you are finding the book useful.
Speaking of generics – they are most useful for building reusable algorithms that operate on various data types while retaining strong typing. Without generics, we resort to either untyped values, or to typecasting (depending on the language).
Untyped values prevent static code analysis at compile time. The errors are then only detected at runtime, which in turn means that many bugs remain undetected for a long time, showing their ugly heads months later when the code is already deployed to production.
Typecasting represents a similar problem, compounded by the fact that it is frequently used in strongly typed languages that lack runtime validation (e.g. C++). An incorrect typecast may result in serious data corruption, which could take days to investigate.
If you plan on building a reliable algorithm, a strongly typed programming language with support for generics may come to the rescue.
I just finished reading this chapter, that is awesome! I have one question. The contract of the data model and the contract implementation will be placed at different layer? and the number of contract will be overwhelming in the future?
Hi Weldon,
To be clear – separation by layers should not affect the number of contracts you will be creating. Layers provide additional isolation and allow you to hide some of the contracts from each other, but the total number shall remain. Overall, expect lots and lots of contracts in a good design. Unfortunately, they are the only meaningful way in most modern programming languages to capture the intent and to decouple implementations. I wish we had smarter languages today, but we don’t;)
Read the chapter. Great example and very easy to understand. One question, why we pass the domain as a method parameter for the Business logic layer(BankingService)? can’t we inject the domain to whole business logic?
You could, and in many cases, this will work fine. However, you will be crossing the boundary from a purely functional design into an object-oriented one. For that, you will pay the price in two ways:
(1) Your interfaces will no longer represent the full contract between the BankingService and the other parts of the system. They will miss the contract with the Domain, which will be bound on the implementation level (i.e. in the constructor, which cannot be a part of the interface).
(2) You will lose the ability to use the same instance of BankingServices across different domain implementations. This might be a stretch, since such capability is rarely needed.
(3) Your BankingServices will now have a state, containing at least the Domain. This will impose restrictions on how you can control the lifetime of the Domain.
On the positive side, you will save on passing a parameter to every method call in the interface.