This instrument follows on from the previousSolving the biggest problem of DDD - how to divide the field", follow the public number (Old Shaw wants to be a foreign language big brother) for information:
-
Latest Article Updates;
-
DDD framework source code (.NET, Java dual platform);
-
Add a group to chat, modeling and analysis, technical exchange;
-
Video and live streaming on B-site.
Disclaimer: This article is limited to business-heavy software system development scenarios, other scenarios are not discussed as the scope of this article.
preamble
The Myth of the Man-Moon: The Tao of Software Project Management, first published in 1975, revealed a law held sacred by programmers that increased developers could not reduce software delivery time linearly, and that the attrition involved was enormous. Nearly 50 years later, there are phenomena in my software delivery experience that break this law, and I was deeply shocked by these phenomena, but I didn't associate them with the "Myth of the Man-Moon" at that time. Recently, while thinking about "how to present the benefits of our DDD practice to you", I had a flash of insight and realized that we have actually achieved the ability to effectively shorten the project delivery cycle by increasing the number of people, and I realized that we have really broken the "Man-Month Myth".
It's the same story.
I'm in theThis is how I "PUA" people in order to land DDD.In the article, about a team landing DDD practice experience, here is a small episode, in our refactoring system the most difficult moment, that is, the most complex order module throughout the lifecycle, our progress is under great pressure, the team expects to be able to carry out incremental delivery, piece by piece to deliver the test, and the order of the "create - deduct inventory - payment success! The whole logic of "Create - Deduct Stock - Payment Success" is intertwined and needs to be fully realized before submitting for testing. Evaluating this, if this piece is developed by a single developer, it will take about three days, while we expect to finish it in one day, so we instinctively thought of a way to do it: "add more people". But we also know very well that according to the past experience, the loss of additional people must be very huge, three developers involved, it is almost impossible to finish in one day, but we have no other choice.
So, I called the three developers to the conference room, in accordance with our DDD workflow, spent nearly an hour to confirm the "domain model", "create order command", "order creation success event ", "order payment success event", each "event handler" logic, front-end interface definition and other design options, and then divided the labor respectively responsible for the "order handler Then, they are responsible for the development of "order processor", "event processor" and "front-end interface".
Surprisingly, based on this division of labor, the team quickly completed their respective work, and before the end of the day, the team completed the code merge and co-tuning. The unexpected progress brought us a slight surprise, but we quickly devoted ourselves to the subsequent work, and didn't have time to think about it deeply.
And since then, the team's delivery process, similar to the response to unforeseen events, has been replicated many times, and it seems that our division of labor could have been done at a much finer granularity, allowing the team to shorten the delivery of requirements by increasing the number of people.
Why is that okay?
As our team revisits this phenomenon, we can see:
-
We have clearly divided the delivery process into two phases, "modeling and design" and "coding", where the capabilities required for "coding" are patterned and replicable.
-
The way our code is organized, it's very conducive to division of labor;
"Modeling and design" and "coding"
Modeling design" is the process of inputting demand information and outputting solutions, and it is a decision-making process, which is essentially the process of transforming "uncertainty" into "certainty" as far as possible. This process, in essence, is to transform "uncertainty" into "certainty" as far as possible, which requires demand-side and decision-makers to build consensus and make design conclusions. This stage cannot be accelerated by adding people, but at the same time, it does not require a large number of extensive participants, which is essentially the participation of "decision-makers".
Once we "modeling design scheme" is determined, and "code writing" to do is in accordance with the "model design" to write deterministic code, this process is essentially This process is essentially "doing execution", once the team members have adapted to the team's code style and pattern, basically does not require much thinking, you can write code "in line with expectations", because the "expectations" has been "modeled" by the "expected". Because this "expectation" has been framed by the "modeling design". And in practice, we found that for a newcomer, through less than a week of learning and imitation, can master this ability.
Therefore, the whole process of our development team becomes two things: "making decisions" and "doing execution", which is also a process of rapid convergence from "uncertainty" to "certainty". It is also a process of rapid convergence from "uncertainty" to "certainty".
Collaborability of code styles
I'm in theThe right posture for writing code after DDD modeling (Java, dotnet dual platform)" article shows you the way our code is organized, and I show you how it's organized in the video "Master This Model and You Can Design Everything" (/video/BV114421Q7vp） In the introduction of the business system, the core is "Command-Event", all the business of the system can be mapped to this model. With the combination of DDD+CQRS+Event Driven, we find that the code is split into independent business logic units by one "CommandHandler" and "EventHandler". Processing unit, the collaboration of these units, in our "modeling design" stage has been determined, therefore, the developer to do is to complete this one by one to fill in the blanks, the completion of the code is written, the mental burden is very small.
The smallest granularity of our division of labor is the "CommandHandler" and "EventHandler", which is much more granular than the traditional CRUD division of labor by module, which means that the team can deploy manpower at a much finer granularity, with almost negligible wastage. This is much more granular than the traditional CRUD division of labor by module, which means that our team can deploy manpower at a much finer granularity, with almost negligible wastage.
We even stipulate that "When you're uncomfortable writing code, odds are there's something wrong with the modeling design", requiring feedback from developers and timely modification of the iterative model design by designers to ensure, as much as possible, that when developed, the code isContext has access to information that supports the realization of the logical unit's objectivesThis makes the entire development process silky smooth.
Back to topic.
In the process of practicing DDD, we realized that in the "code writing" part, we can deploy human resources very flexibly, and even the developers who are temporarily transferred into the project can complete the code writing according to the design efficiently, and the loss of which is almost negligible.
Based on this situation, we believe that an R&D team can achieve such a model as one modeling designer plus multiple implementation developers, and this team model, I believe, is what many teams expect but find it difficult to bring up the efficiency of collaboration.
Now it seems that our practice does, so I guess the man-moon myth is no longer a myth.