This instrument follows on from the previousWhat comes first, the chicken or the egg? This is the biggest dilemma in getting domain-driven design off the ground》
/s/lzAZXgchCg_VyLmyo2N18Q
Background
In 2023, I joined a brand new team as a technical leader, which can be regarded as "parachuting", and it has been more than one year since then. So far, the team has completed the internalization of domain-driven design practices, requirements analysis, domain modeling, code writing process, all follow the methodology in line with the concept of domain-driven design, the team members of the design thinking in the process of practice has changed, the identification of boundaries gradually internalized into the underlying values.
preparatory phase
Before I first joined the team, I had the experience of successfully landing a team, and also had the case of swearing but ending hastily, more importantly, the success came first, and the failure came later, after reviewing and reflecting, I realized that I had to build up enough trust on the basis of the foundation to lead a team into the door of domain-driven design, after all, this is a war of values, so building up the trust became my most Therefore, building trust became my most important goal in the preparation phase.
To gain enough trust, we need "superior trust" and "lower (same) level trust", to the upper to do adequate communication and expectation management, to ensure that the goal achievement continues to meet expectations, to the lower to show technical ability and technical judgment, to the team to bring consensus decision-making and technical landing, such as distributed context delivery system, with the help of this ability, I have realized the system from single-tenant to multi-tenant architecture change, and also gained the ability of full link gray scale. Technology landing, such as distributed context delivery system, with the help of this ability, the system has realized the architecture change from single-tenant to multi-tenant, and at the same time also gained the ability of the whole link gray scale, this ability I have a special introduction in the previous blog.
Elevated trust in the team, in turn, creates mutual reinforcement. Elevated trust in superiors leads to enhanced endorsement of my decisions by superiors, which enhances collaboration and cooperation among subordinates, and the trust of subordinates (at the same level) creates positive feedback to superiors, which enhances the trust of superiors.
Of course, I am well aware that all of this assumes that the culture of the team you encounter is open and positive, otherwise no matter what you do, you will not be able to build the necessary trust.
make a firm resolution
After six months of bonding, most of my suggestions and decisions were starting to be recognized and supported by the team, and I felt ready and just waiting for an opportunity, which happened to come along.
The team faced a relatively large-scale requirements, comprehensive judgment, to meet the needs of basically similar to rewrite a core module, we face the biggest challenge is: the old code has been overwhelmed, has been the team has lost control of it, the speed of iteration and the quality of the delivery of both out of control, to do a large-scale large-scale iteration in such a context, everyone does not have the confidence.
And I think this is a once-in-a-lifetime opportunity to motivate the team to make a determination to innovate. After a short period of thinking and preparation, finally, I decided, to enable the DDD tactical framework to realize the requirement. The comprehensive rationale is as follows:
- The team was unhappy with the old model, the delivery process was extremely painful and risky in its current state, and there was a desire to improve the status quo;
- There is a mature DDD tactical framework, and all the team has to do is perform a simple familiarization, the learning cost is very low, and you can be up and running within a week;
- The team has reached a better state of trust in me, and there is a high probability that this decision will be supported by the direct reports;
- Most of the team has an open mind;
So I spent two days building out the project engineering from scratch using the DDD tactical framework, integrating it with existing systems, and completing the overall CI/CD configuration so that the team could get right to work writing business code.
Immediately, I launched a one-on-one communication with the back-end developers, in order to confirm everyone's true feelings, and to make sure that everyone is honest enough in the overall collaboration, because only the real feedback from everyone is good for the whole thing, and can be corrected along the way to ensure the ultimate success. During the communication process, I asked everyone a few questions:
- What do you see yourself growing into a year from now if we keep up our current pace?
- Would you be willing to believe me if I said that there is an opportunity to revolutionize the team right now, and if it comes to pass, the picture I painted earlier of what an ideal team would look like will become a reality.
- If I say there is a DDD tactical framework that you need less than a week to navigate it, do you cause to believe me.
Luckily for me, everyone gave me answers in the direction I had envisioned:
- If the status quo pace is maintained, there won't be much growth in the future, nothing new, just a repeat of CRUD;
- It doesn't hurt to learn more, and whether or not it works out as "you" say it does or not, it's still rewarding for you;
- It feels like it might not be as easy as it says, but willing to give it a try;
After getting positive feedback from everyone, I communicated with my superiors about my thoughts on the whole thing, expressing our current predicament and the right place, right time, and right people for the reform, and eventually got their support:
So, we finally finalized, on the new framework, on DDD.
Toughest moments
Everything is difficult at the beginning, we introduced the DDD tactical framework of the first iteration of delivery, but also the most difficult stage, although psychologically prepared, but the whole process, the team is still under a relatively large amount of pressure, these pressures mainly come from:
- Time constraints and limited delivery schedules;
- The interface between the old and new services has exceeded projections;
All of the issues ultimately pointed to one scarce resource, time, so we took three actions to ensure that the end result was a success:
- Expressing frankly with the business team as well as with the superiors, the reality of the workload, the team ended up buying some extra development time as the actual workload was higher than expected;
- Locked up in a conference room and doing closed development, we found that with the DDD coding paradigm, once modeled, we could assign a complex process to multiple developers on a "command-event" basis, allowing the team to collaborate quickly to complete a complex function;
- The team organized a certain amount of overtime, and this period, too, was the hardest time in almost a year;
Fortunately, with these initiatives, we finally completed the delivery and got results that met expectations. So, after the delivery of the first iteration was completed, initiated by the product team, we used the same methodology to complete a larger refactoring effort of the core modules.
These first two big iterations, which lasted about 3 months or so overall, were the busiest, the toughest, and the fastest-growing period for the team, and in retrospect, everyone agreed that they were the most necessary.
Changes and benefits
After the second refactoring effort was completed, it became apparent to the team that something had changed:
- Business modeling, to the point where writing code doesn't require much thinking, the code can be aligned with the model, and there's no need to do translation work anymore;
- There is no longer a sense of burden on the iteration of features, and it feels like the code is manageable, thanks to DDD's code organization, which makes the scope of impact of system changes, always easy to control, and the impact surface of code changes very manageable;
- Online issues are easier to fix than before, and the new framework is more significantly robust in terms of data consistency, making it easier to ensure that data is correct;
Our workflow has also evolved gradually:
The biggest change in workflow here is:
- More attention is paid to whether the design of the model meets expectations;
- Evolved from taking people modeling to the point where team members could model independently and largely meet expectations;
- Once the model is finalized, the code is essentially finalized;
- Once the modeling was complete, workload estimates were much more accurate than in the past, and omissions were drastically reduced;
An unexpected bonus
A month before we decided to start DDD landing, our team came a new colleague, this is a fresh graduate, with a foundation in programming and a period of internship experience, this colleague's performance in the whole process made me realize that domain-driven design is not something out of reach, on the contrary, it is very bottom of the cognitive, for the newcomer, in turn, to accept and practice, in turn, not too much of a For newcomers, it's not too much of a burden to accept and practice. Below is a list of my observations:
- He was able to get started and complete the development of functional modules using the DDD tactical framework in about a week's time
- He was able to engage in modeling along the lines of DDD after 3 months of training
- He designs models that will not adequately analyze business scenarios due to lack of experience
Based on these phenomena, we find:
- It will be very easy to learn DDD in an environment that has already landed DDD;
- DDD's tactical framework is extremely important and lowers the threshold of understanding for newcomers to learning;
- More business and design experience is required for good modeling;
I think that if a team comes up with DDD, will people think that the process-oriented style is "weird" instead?
Inception
Above, is the whole process of our team landing DDD, it seems that a lot of key decision points are somewhat fantastic , why the team will be through two or three months time to change the thinking, you can use the DDD model to think and modeling, and behind all this, there is actually a dark line.
You should have seen the movie "Inception", the whole movie is about "implanting a point of view into a person's mind", which is very sci-fi. But I think I have been explaining the value of domain-driven design to the team from the very beginning, just like implanting a point of view, but without using the term "domain-driven design". In every business analysis, technical solution discussion and decision-making process, I would express to everyone that "the scope and boundaries of the problem are important", "the scope and boundaries of the solution are important", "the scope and boundaries of the code's responsibility are important". I kept repeating "scope and boundaries are important", and I kept correlating "scope and boundaries" with "costs and benefits". I kept repeating "scope and boundaries matter", kept correlating "scope and boundaries" with "costs and benefits", and kept corresponding "scope and boundaries" with specific examples we encountered.
Eventually, the idea that "scope and boundaries matter" gained traction, and based on that traction, our decision-making logic converged, and our modeling mindsets began to resonate.
the ultimate axiom (Buddhism)
Although I've used the word "PUA" in a headline-grabbing way, I believe that the ultimate formula for success in teamwork is:
- Sincerity is the greatest PUA
- Believe in the "Power of Belief"
If I'm not sincere enough, no one will believe me, and if no one does, then nothing stands, with all of you.