The technical challenges we met in the practice of Domain-Driven Process
The biggest challenge is absolutely the strategy design part, that is, how to divide Bounded Context correct and build domain model. It's hard to express it very clear just with words, I think the best way to work it out is to practice more and learn more from masters, for example, try Event Storming.
Afterward, don't underestimate the challenge of the technical part if the team has no experience in any Domain-Driven Development. Unlike many people saying that the technical part is not that important, if not implemented in a proper way, Domain-Driven is hard to make real sense. We met some typical problems when we did the practice, fortunately, we solved those problems very well.
1. Developers think that Event Sourcing is not important, for example, in the previous situation, you only need to change the property Job.Status="Published" when you need to publish a Job, but now you need to define a JobPublishedEvent. Sometimes, one change needs to define a lot of events, such as CompanyNameChangedEvent, CompanyEmployeeAddeedEvent. Most importantly, how to define the granularity of the event?
2. As the system was divided into lots of subsystems based on Bounded Context, the interaction between systems is more complex. Change data through the way that to call different Repository in the same Controller in former situation is not usable here.
3. Since it requires to store QueryModel separately when using CQRS to do inquiry, write-in and read are in the same database is more complex compared to the traditional database-driven development.
4. The version management of the event, such as change, delete and increase of the event all need to consider the effect caused by event replaying and Domain Model.
5. How does CQRS guarantee the timeliness and consistency of data? For example, I changed a company name in the company detail page and clicked save button to navigate to company list page, QueryModel may still not update.
How does Domain-Driven Design benefit us and our clients together
1. Do Right Things: the high efficient communication between Domain Expert and the team guarantees the setup of models that correctly reflects business rules. Since the developers have code that can be used directly, as well as data and behavior because of Domain, it's very convenient to do unit test, because Domain doesn't rely on third-party data storage, which ensures the implementing of business.
2. It highly improved communication efficiency. We all know that one chart speaks more than a thousand words. As for developers, what they really need is"talk less, show me the code!". The code is not only easier for developers to read, but the Code (Domain Object) is also the latest requirement, the running up requirement.
3. It highly improved the efficiency of adding new resources to the project. When a new resource is added to the project, it mainly requires to check out the domain model and test domain model, then you'll understand nearly all the business rules of the system through this process.
4. The technical part of Domain-Driven brings huge convenience for adding new functions or making extensions to the system. Let me give a few examples here:
a. Due to the use of Event Sourcing, it's easy for us to check historical data, that is, we only need to assign a point-in-time, then we only need to replay to this point-in-time when we do the Event Replay.
b. Operation log: formerly, there would be Log all over the code if we want to record operation log, but now we just need to replay events, then you can check any log you want to see, it can be simply realized by replaying event stream of database storage.
c. System communication: the communication can be realized via Event Publication, other systems just need to subscribe to our events, there's no direct dependency between our system and others.
d. It greatly improved the convenience to add new functions to the system, in most situation, it's just an event subscription when adding new functions.
e. CQRS and Query model highly improved the query performance of the system. I don't need to do any modification to the write-in end including the class files when I need a new interface. Is it quite consistent with the rule that closed to modification and open to extension (OCP)? We only need to build something that similar to a new EventHandler and Replay the corresponding event.
f. Because of used Event Sourcing, the system compressive ability can be greatly increased through events integration between systems, such as message queue publishing and events subscription. We can put the events in the queue, so it won't lead to the frontend system crash in case the system processing later was not handled in time.
g. System performance is highly improved. There is only insert operation at the write-in end, no modification operation; and there is only Read operation in the read end. As a result, the bottlenecks of output storage and read can be greatly eased.
5. Developers can focus more on solving business. As everything is events, developers can ignore data storage after the basic library realized, and spend most of their time writing business code. When don't care about how to store data, then there would be only two operations for data storage:
Then the event subscriber only needs to add an EventHandler.
6. The system was well decoupled and business logic is concentrated in the Domain, unlike the previous situation that the business logic exists in many places, now you don't need to worry too much when you modify some functions.
7. Don't need to worry too much about the developers, especially the effect to other functions, caused by the incorrect code which spreads all over the system that was written by the junior developers, would be highly reduced. Review code is actually reviewing the unit class of business implementing, so don't need to worry too much about the incorrect part that caused by the technical implementation, because the development cost can be reduced by the appropriate balance of team members when the basic library was well written.
8. Finally, the benefit of more easy to do changes and add new functions, exactly supports the "embrace changes" of Agile philosophy, is it right?
How does Domain-Driven Design benefit us and our clients together
Domain-Driven Design has many benefits, many concepts, relatively high barriers and high demand to personnel. At least there should be a leader in the team, otherwise, the cost will be high, especially be careful to use Event Sourcing. Domain-Driven is particularly suited to projects that have a relatively complex business, for those small projects, CRUD is still a good choice.