today I want to share some glimplses of what is Domain Driven Design.
One of the main ideas of DDD is to make the problems to guide software design, and not make software to affect problems of client. There is a popular joke, that computers help to solve problems, which didn't appear before inventing computers.
So, the same with design of system. Design system in order to solve problem, not just use system to create another problems for business owner.
How this can be achieved in order to avoid displayed situation:
First of all, you should apply the following:
- Ubiquitous Language
- Bounded Contexts
- Aggregate Root
I hope that the first bullet item is easiest to explain. I give you one example. Here in Ukraine, I volunteered for stationary company. And in Ukrainian following items are called file:
But for majority of programmers, file is as usually named part of infomration on disk. So it took time to distinguish what is file and what is Packing file ( not zip, huh ).
In phrase bounded context following is understood: depending from words around, different word from ubiquitous language can be applied. I can also name bounded context with word dialect. It's like speaking with user of your program you'll have one vocabulary, if speak with developer of some program you'll have another vocabulary. One of practical usages can be the following. Let's say you have 3 developers. Then one developer can work with accountant, another with security guy, and third with sellers, and each one can have his own solution, his own source code, and/or you can think about sharing some common source code between them.
And aggregates is compostions of objects. For example order is compostion of: products in order, prices of order, discounts of order, delivery details of order, type of order. As usually you can make three kinds of aggregate rules: identity, reference, operation.