DDD implementation experience sharing-value orientation, from top to bottom (the first in the circle to eat Crab DDD implementation plan)

Read the catalogue:

• 1. Background

• 2. Start with the business

• 3. From strategy to tactics

• 4. Drive research and development with external forces (QA, leadership, automated testing)

• 5. Domain model and the core of the SaaS platform (value maximization)

• 6. Finally

1. Background

DDD itself is not covered by the technology, this article to share my experience in promoting DDD or the implementation of DDD in the process of learning and valuable experiences. This proved to be a viable option. Using DDD is one thing, and promoting DDD is another matter. Perhaps there is an objective and rational promotion of technology, but I can only say that DDD is very special.

We all know that we do not have a good ddd problem, so that one or two people with good ddd is not a problem. You may have strong code control, or your team will be interested in DDD, and under your leadership you will have to write code for DDD mode with little problem. But as an architect, it is our job to promote or introduce a technology or best practice that is appropriate to our business model. You might be promoting performance optimization, interface design, and so on, which is fine. But it's hard for you to promote something that has a strong sense of subjectivity in it. Because each person's mode of thinking is different, the understanding of the problem and the way of abstraction are different. So how do you get people to agree on the abstract understanding of DDD?

You might think I'm bragging. B, your company can implement DDD. To tell you the truth, we implemented DDD, and the effect was obvious, very successful, there is a picture of the truth. I have a way for our top leaders to agree to this value. If you promote DDD from the perspective of technology, then I can be sure to tell you do not work, in any company implementation is impossible, unless the boss is your father. To be successful, you have to let a leader who does not know the technology feel its value and solve a certain pain point so that you are half successful.

In the emphasis, as an architect, in our brains every day is not a specific technology, but the overall. What you have to control is a face that needs to be considered comprehensively. You can go back and study a technology yourself, like I've been learning Java and GO for a while. Technical staff to learn every day, know more to learn more things, this is reasonable and normal. But you need to know what it's like to be an architect, to figure out what your goals are, and this is the most helpful reminder and guidance from my current mentor (and I really appreciate my leadership).

Therefore, the title of my article has value-oriented, which is in line with the rules of business operations, but also in line with our people's way of thinking. Technology-oriented, is the thinking habits of technical personnel. That's true, but if we're going to influence others, we're going to jump in and think.

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M00/77/11/wKiom1ZiVmHTP54zAACWwIMknos234.png "title=" Untitled _ Look at the picture king. png "alt=" Wkiom1zivmhtp54zaacwwimknos234.png "/>

The first edition was designed by me, and it felt good.

2. Start with the business

The implementation of DDD has a premise, it is to solve business problems, not to solve a technical problem. Or, to be precise, it is the solution to the business system problem, not the non-functional technical problem. This should be understood clearly. Then you have to consider from which level you cut into the entire research and development process, let ddd things play a role in a certain link, short-term not too urgent, not all the promotion out of breath. This will make you feel like a technical paranoid person, not a rational architect. Avoid.

How to create value from the start of the business. Here is a pain point is the business terminology, business model is not unified, communication costs are too large. If you can reduce the cost of communication between the product and the technology, you create value, and the value is huge. You can introduce the knowledge of DDD to solve. One of the tips is that you just start not to mention some of the professional technical vocabulary such as DDD, you have to guide this aspect to go. You can say we need a manual that contains a professional business terminology to explain, if possible, a basic business structure that contains points. Guide and co-operate the way the product is organized, and you are modifying and collating it because you are aware of the entire path of DDD.

At this point you are already implementing DDD, and don't think that DDD is the code.

When the business manual is gradually formed, it will be guided naturally to the technician. And then you're looking for a pain point. Tactical design is introduced into the research team. In that sentence, don't stress the ddd tactic too much. From the beginning to the outside if you do not mention the concept of DDD so that DDD landed is the ideal.

Slowly introduce high cohesion and low coupling from OO perspective, and then use DDD tactics to help develop and understand.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M01/77/10/wKioL1ZiWBTBWClyAACwpcUo_qE317.jpg "title=" dsc_ 0128 (1) _ See figure Wang jpg "alt=" wkiol1ziwbtbwclyaacwpcuo_qe317.jpg "/>650) this.width=650; src=" http://s1.51cto.com/ Wyfs02/m01/77/11/wkiom1ziwbnymvvqaadituqwa6c069.jpg "title=" myxj_20151112161700_fast_ see king. jpg "alt=" Wkiom1ziwbnymvvqaadituqwa6c069.jpg "/>

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M01/77/10/wKioL1ZiWJmBxp_yAAIBdZbY-OI772.jpg "style=" width : 500px;height:376px; "title=" Myxj_20151112161734_org_ see king. jpg "width=" "height=" 376 "border=" 0 "hspace=" 0 "vspace= "0" alt= "wkiol1ziwjmbxp_yaaibdzby-oi772.jpg"/>

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M00/77/10/wKioL1ZiWJqgKXcmAAFxKXXy8H8378.jpg "style=" width : 600px;height:451px; "title=" Myxj_20151112161818_org_ see king. jpg "width=" "height=" 451 "border=" 0 "hspace=" 0 "vspace= "0" alt= "wkiol1ziwjqgkxcmaafxkxxy8h8378.jpg"/>

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M02/77/10/wKioL1ZiWJzjSZnjAAHg14zniZE453.jpg "style=" width : 600px;height:451px; "title=" Myxj_20151112161850_org_ see king. jpg "width=" "height=" 451 "border=" 0 "hspace=" 0 "vspace= "0" alt= "wkiol1ziwjzjsznjaahg14znize453.jpg"/>

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M00/77/11/wKiom1ZiWDKx3csGAAGzjoCQRqA415.jpg "style=" width : 600px;height:448px; "title=" myxj_20151112161920_fast_ see king. jpg "width=" "height=" 448 "border=" 0 "hspace=" 0 "vspace = "0" alt= "wkiom1ziwdkx3csgaagzjocqrqa415.jpg"/>

3. From strategy to tactics

Solves the business problem, brings the value. This is a good point of entry, we continue to move forward. Slowly start introducing the strategic concept of DDD, if you want to be trusted and responsible.

Introduce strategic design patterns and begin to communicate and guide with professional DDD strategy terminology. Of course, if your communication and discussion is the best of agility, quickly agree with the whiteboard. After a period of time, a concept was consolidated through the present formal meeting. This stage requires a lot of sharing and training to get this atmosphere up. Reach a consensus first.

So far we have started to promote DDD, and several research and development departments have seen its value. Good things don't you say more, the eyes of the masses are discerning. We also carried out unit tests, which is how proud. Core business objects We slowly began to introduce unit testing, hands-on teaching and research how to write.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/77/10/wKioL1ZiWN2SL0NpAAA3-MdxnPQ640.png "style=" float: none; "title=" 29.png "alt=" Wkiol1ziwn2sl0npaaa3-mdxnpq640.png "/>

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M01/77/12/wKiom1ZiWHSjaoLTAAF3a0CLRT0711.png "style=" float: none; "title=" 30.png "alt=" Wkiom1ziwhsjaoltaaf3a0clrt0711.png "/>

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M01/77/10/wKioL1ZiWOGxx7RgAAFmUMiJBlc062.png "style=" float: none; "title=" 33.png "alt=" Wkiol1ziwogxx7rgaafmumijblc062.png "/>

4. Drive research and development with external forces (QA, leadership, automated testing)

Sometimes it takes some external force to help us promote something, which should be a common way of doing things. So what power does DDD need to use to make the promotion easier?

You can use QA to emphasize quality, such as introducing Codereview and incorporating your ddd into it. Keep your goals in mind.

You can also use your leadership to promote, of course, there are leaders to help promote is happy, but you have to do pre-sales work. Don't push it, it's counterproductive.

You can also use the implementation of automated tests to promote your domain model refinement. Through unit testing, the research and development of the domain model of high cohesion and low coupling is gradually emphasized.

5. Domain model and the core of the SaaS platform (value maximization)

In fact, to the end of the Enterprise SaaS platform to create the first need is the business model. You can use this value to maximize the value of DDD. And the truth is true. The people who study SaaS understand that the core business model is basically very little changed. Peripheral personalization is based on the core model in the extension.

6. Finally

In fact, it's hard to know the details with just one blog post. I'm just sharing some of my own options and ideas for the gay guys who love ddd. In fact, there are a lot of valuable things to share, I will be in my next book in detail to share. ("e-business Platform system Architecture Design", a system architecture to explain business model, which will include DDD, SOA, SAAS, grasp and other important technical concepts.) In this first to play a small advertising promotion. )

Finally, I would like to say that as an architect you should know "value-oriented" and "risk-driven". To create value for enterprises, to avoid risk for enterprises. You just have to be good at these two points is already quite powerful. To have patience, to be responsible, to be a mentor, a lot of times technology is to guide, architecture is in the continuous evolution, so do not hurry. The aim is to make it, not that I have tried unsuccessfully.

King Qingyue Culture

Source:http://wangqingpei557.blog.51cto.com/

This article is copyright to the author and 51CTO shared, welcome reprint, but without the consent of the author must retain this paragraph, and in the article page obvious location to the original link, otherwise reserves the right to pursue legal responsibility.

This article from the "humble if foolish, thirst for knowledge" blog, please be sure to keep this source http://wangqingpei557.blog.51cto.com/1009349/1719803

DDD implementation experience sharing-value orientation, from top to bottom (the first in the circle to eat Crab DDD implementation plan)