Conclusion on the relationship between component business model and DDD

The first time I heard from IBM's lecturers (Hi, Derek) about Simm and soma, it was the spring of last year. Although he had little ink (it is said that IBM's methodology on soma was not yet systematic at that time, but it is still attracted by the component business model. I was a fan of DDD at that time. I didn't think more about DDD as I do now. At that time, as long as it is related to DDD, I will consider whether it has a mysterious extension relationship with DDD. In this way, CBM is included in my scope of attention.

To be honest, CBM initially impressed me, mainly because it has a clear responsibility layer. In my impression, the DDD used in large-scale structure also has an obvious responsibility layer. Of course, it seems that these two things are not exactly the same, but they do have some hidden shadows. Now I can say responsibly that I have also found the connection between the two.

Because the DDD comments version has been published, I will take a look at the book reviews of the Chinese version of DDD. DDD is a good book. Many people still say this until now. After a few questions are raised regarding the translation of the Chinese version, some people wrote: "The first time I heard about the concepts of value objects, entities, and aggregate, the things behind them seem very empty ). In fact, I disagree with this idea. As a basic construction block, the previously mentioned concept is indeed a place where DDD is more eye-catching. However, being eye-catching doesn't mean it's okay. What is the specific problem? I want to hold down the table first. The main reason I disagree with this idea is that the last few chapters are much better than the previous ones.

If you read the strategic design section, you will find that the Resposibility layer I mentioned above is very practical. It is wrong for many people to read DDD as they read design patterns. If you haven't moved your eyes from design to the field, you have misunderstood Eric.

Back to component business model, I don't want to argue with people about the relationship between business model and domain model, whether they are integrated or independent. This makes no sense. What we can find is what it can do for our system, which is enough. The most close relationship between CBM and DDD is not in responsibility hierarchy, but in service. This is also the main reason why DDD is listed as a reference for Soma recommendation.

Today, I wrote a small conclusion. In fact, this week (in fact, it can be traced back to the project I attended on a business trip to Beijing last week) I am exploring the association between DDD and CBM. The process of inquiry is very interesting. I will gradually release my inquiry process in my blog later.