A year ago, Maxim Arshinov (marshinov) made a presentation "Instant Design". Great report, charismatic speaker, useful materials at the end. This report changed my understanding of what I was doing - which of us has not tried to intuitively apply pipeline architecture? And then there are elegant solutions multiplied by DDD! From this began my journey as an evangelist in domain-specific design.
DotNext 2019 Moscow is coming soon. As always, we are waiting for a review of new features, exchange of experience, best practices, architectural solutions - for this we all love conferences. In the list of reports is the wokshop “The Shine and Poverty of the Subject Model,” which drew my attention. Quote from the page:
Fowler and Evans consider the anemic model to be antipattern. However, many code bases that the speaker has worked with are implemented in the style of an anemic model. The report is devoted to comparing the strengths and weaknesses of both approaches and the non-obvious details of the implementation of the domain model in the OOP paradigm and in the functional style.
The production itself makes one think that a crisis has emerged in the development of the DDD movement. A small analysis of the dysfunctions of use and the reasons for such distortions under the cut.
Dysfunctions of the use of subject-oriented design
The present situation has some historical development. Let us consider in stages how the situation developed.
Promotion
Maxim, in my opinion, is the most famous developer in the community, who for many years competently promoted DDD, talking about the concept, use. Honor him and praise! And I give Arshinov as an example, only because I consider him the best speaker of dotnext at the moment.
Dysfunction # 1: Profitability
marshinov has written several articles on the cost of implementing DDD practices. The conclusion is simple - subject-oriented design is expensive. And the judgments are fair - Evans himself in his book notes that the team must be very skilled, and therefore expensive. In addition, these are continuous improvements, which is expensive for a business. Well reveals this topic article by Martin Fowler on the costs of architecture . I dare to assume that the question of how much a business wants to spend resources is the solution of its problems, first of all, for himself. And the customer does not solve any major problems of his own, then even SOLID will not be able to sell him.
It is very important to understand the antagonism of business requirements and architectural decisions. Businesses need the cheapest solution that will cover their needs (and better the first time and forever). Teams want to make tools and solutions that most correctly, quickly and beautifully solve business problems, but especially the task of adaptability to changes. The nature of these needs (in fact, polar contradictions) is very dialectical, which in turn means that it is impossible to realize the implementation of complex requirements without elaborating the architecture, and condominiums cannot be built instead of a doghouse. No, of course everything is possible. But the fact is that high demands on the one hand generate corresponding ones on the other. Like the pathological weakness of one side, it limits the other.
And so, in an attempt to match the business, a second disaster formed ...
Dysfunction # 2: Instant Design aka Anemic Model aka Consent
Obviously, a certain community of programmers is trying to bring to the masses practices cheaper subject-oriented design, reducing costs and applying new techniques: RailwayProgramming, Pipelines, Anemic model. A cool approach, many advise, this can be taught to any programmer: "here you have SeedWorks with interfaces, implement them and everything will be." And it works! but this is not DDD.
You do not quite understand Evans.
- Who does not praise Klopstock? But will everyone read it? Not. We want to be revered less, but read more diligently! (Lessing).
I'll explain now.
Anemic model is an antipattern
The fact is that in science there are two research methods - descriptive and analytical (hello Adam Smith). When we make the Anemic model, we simply describe what we see, and live with it as it is. This reflects a business and is sufficient to realize a business opportunity. An important principle described by Evans is not to waste resources on an ideal system, but to simulate the process as it is, and only then begin deep refactoring. And at what point with the Anemic Model can we move on to deep refactoring? Is it supposed to start it at all? It seems to me that the answer will be negative, and the model here remained as atavism.
That's just the model itself is not important! Tactical patterns are not important! Limited contexts, a single language, and large-scale structure are important. That is why it is necessary to approach the business entity from the analytical side, describing the aggregation root, value objects, business methods, and as a result, understand the boundaries of a limited context.
On the one hand, an anemic model and a cheap solution is good, because novice programmers will have an understanding of a new dimension in programming - business objects. However, taking a similar position you are doing poorly for yourself. By hiring a weaker programmer each time, who can do much the same thing as copy-paste, do you have an argument for the business to look for a stronger employee?
But it could not end with the inglorious end of the DDD idea.
Dysfunction # 3 Life after business objects aka complication of tools.
In the spring of 2019, Maxim and Wagib told us about how features F # did not come in C #, about making the model correctly in F # easier, about how to not violate OOP in functionalism. Now the masses could believe that DDD was not only not affordable for ordering music, but not for all mortals, but only those who knew functional programming.
Listen to where they all drive - now subject-oriented design is expensive, you can only write effectively in F #, and generally works sometimes, sometimes. There is no faint impression that in this way the authors of books and articles distract us from the most important in DDD, luring the game with ideal tactical patterns. And they must be beautiful and licked, otherwise ...
Of course, there is no other way. All these abstractions are important in a BrainSrorm conversation, when everyone needs to understand everything very clearly. Or if you find managers and analysts who will look at your code - a single language (if the code is UL).
However, as mentioned above, the opposite will seek its own way. The approach has taken root where the business is willing to pay for the development of functionally unobvious code - this is just a market niche, not a rule.
What is absolutely disgusting here is the simple human nature of the attitude towards achievements - people value such achievements in themselves, without giving them a form or applied application. And here the list can be long. Einstein gave us STO, GR, FE, he is an excellent scientist, but ask the average person about the relativistic movement, time - he doesn’t need Einstein, but in a “smart” conversation one could mention that everything is relative. Ask a person about Freud, an excellent psychologist who has made serious progress in science, if this person uses psychology, for example, to interpret yesterday’s nightmare - he won’t, but he will someday mention the sexuality and psychology of the masses. Marx is the one who made science out of sociology and history, but nobody needs scientific socialism, but everyone can talk about progressive tax and honest democracy. Problem-oriented design also has no form - Eric Evans has opened new heights for us, providing an excellent tool for reducing software complexity, but supposedly how to use DDD and what to do is not clear, and it doesn't work at all.
I don’t know how about the rest, but with the subject-oriented design you can understand the reasons for the misunderstandings.
The reasons for the crisis of use
The principles of subject-oriented design are very tempting, logical and holistic. Everything is nearby - Agile, CI, SOLID, GRASP - all the best that the developers came up with. However, it is not enough to believe in DDD, or business, or experience. Many people from the community, just developers from integrators and outsourcing offices, have the imprint of business values ​​in their activities, and with all the desire they can’t try the leading methods and practices, because the price of these trials and errors is not included in the price list - a completely materialistic finale.
There is absolutely nothing left for such commands except how to make programming profitable, using simpler approaches, hiring developers more cheaply, but an anemic model can be hooked "by half an inch". And if you are a developer of one of the developers who come for an hour - you do not have significant prospects - you must complete the order, and creativity is encouraged only on the github in the home project. DDD is not a luxury for an architect, not a customer show-off - the team level in a separate Enteprise. You need to realize the following - while you are in a production relationship with those who sell your skilled work to those who pay better, you will only do what the customer paid for - the implementation of business tasks. Unfortunately, testing best practices does not always lie in the plane of these tasks.
Total
DDD can always be tried if you are describing real-world objects. This approach can be applied in PHP, and in VBA, and 1C (and the developers apply). The problem of applying the approach is more likely in the plane of communication between people, and technology is more likely to help. Communicate, try, teach others! Boost Softskills, solidarity, unity of purpose. DDD is just a teamwork technique.
And the next time you think about where to go for an interview, carefully consider what you choose - a company mercilessly reselling your skills, or who really needs them to solve specific problems. It is in your power to help such a company be better, to try proportionate methods and approaches, to form a close-knit team, to fulfill your mission as a programmer. The latter is especially important, because for new technologies and goodies, many have forgotten the original purpose of this profession.
Be that as it may, it remains to be hoped that in trying to touch the leading practices, DDD will not be transformed in any other direction for the sake of convenience to customers and teams. I look forward to the upcoming report.
PS The purpose of the topic is an invitation to a discussion. There is no purpose to belittle the merit of any members of the DDD Community. I respect all representatives with respect, which does not alleviate development problems.