Domain-Driven Design
Field drive 15 years ago by Eric Evans solutions to complex software engineering problems raised by the author from the perspective of his many years of software development starting, by introducing the concept of domain-driven design and design patterns series of strategic and tactical approach for software development chaos brought a ray of sunshine.
In the past many years, I have experienced a change from technical positions to management positions, but also deeply aware of the hardships of every software design and implementation of the process, the lack of some scientific management methods, will only make people exhausted, cents no accumulation, especially for the development process, the encoding process may seem tedious, but full of more variables.
For example, when the previous design of the system architecture of traditional enterprise development, often using three-tier architecture, the user interface layer, business layer and data access layer to get started on, but it looks like three separate, but because developers to develop occurred during Some non-standard problems, easy to accumulate a lot of redundant code in a user interface layer and data layer, the middle layer of business but very thin, very few lines of code, just to achieve the output target only. The user interface layer and data access layer can easily become corrupt codes, along with the demand for change, easily become a big ball of mud system.
Especially those core module of the user interface layer code easily broke through the line of thousands, or even tens of thousands of lines of code which are not entirely due to operational irregularities caused, to some extent also due to the individual developer's code does not regulate , broken window effect is formed. No matter what happens, the code will eventually become a feces mountain. If we add the ancients to write stored procedures, I'm sorry, I chose autistic.
Mountain fate feces are often the same, either successful reconstruction, Guards to change it, either abandoned the company, has become an important milestone in the development process of the enterprise, or follow the company together, become a fool's paradise entrepreneurs. What caused the feces Hill? Demand it?
Demand control or not control?
User demand is like a lion in a cage, control or not control, that is the question.
For Internet companies, to some extent, the inspiration comes from the demand for the product manager Zhaxian, to or from competing products (to be copied product) to grasp the function of the different product manager for product planning is always different, and the reason the owner and user feedback is the product of changing needs, the cumulative demand also make developers to modify and exhausted, and Internet-oriented products more often than the finished project-based software for larger groups, have a longer life cycle, development in response to those needs change without restraint, likely to be trial and error, and even affect the survival of enterprises.
Therefore, the art using driving methods designed to transform the structure of the rear end of the table transformation even be a very effective solution, for the reception and for the user, as well as the front BFF born since more emphasis on user interaction data, and excluded from the field of control, (ie Backend for Frontend) (of course, excessive reliance front-end presentation layer, are likely to cause redundant front-end code, in fact, front-end and client code is also most likely to be feces Hill, this is then I do not go into details.)
In addition to the method of Internet companies need to drive the field of traditional software companies also need, in the process of enterprise development, the accumulation of numerous projects, most of the projects there are some general similarities, that is to blindly pursue, while ignoring the software robustness and maintainability of the code, the ability to function strong push down, depending on the project manager for the control of the Party, once mastered excellent communication skills in key positions leave, these projects will be the one I do not know when it will erupt mines. The complexity of enterprise software projects, unlike Internet companies face rapid business changes brought about by fission, tend to be more focused on the complex scale business level, hundreds of large function point of a system, how to ensure quality, time and cost the balance of the three, which is to remain constant problem.
Software needs to make highly variable, and the scale, quality property will also affect the software changes, to break the deadlock, perhaps, the field of drive appears to be a good choice.
Seemingly crack of the Road
However, practice-driven field was full of ups and downs, mainly Evans 's original book, knowledge intensity of thick, even more than the developers keen technical topics. To resolve some technical issues, relying on the resources of the Internet, perhaps the solution to the problem can be quickly found, but the face of the field-driven design, but daunting, though I heard many people say that the concept of time is not short, but always feel that there is no entry.
Conceptually simple, unified language introduced in the field of repositories, entities, value objects, aggregate root, bounded context, context mapping and other terms, the understanding seems easy, but to put it into practice is not easy. In particular, the need to take these things into the real business process even more difficult. Domain-driven design method, unlike those technical books in general, the method of holding a book, you can always find a point of practice in their own company. Evans 's book or, other books or whatever, but the method, rather than a well-established immediately be able to use the program, you need to team spent a lot of time to apply in practice.
For example, practice-driven architecture is one of the most common areas of a simple four-field drive hierarchy in the degree of separation can not be effectively understood the concerns of the premise, the same structure of the code can become feces mountain, but it seems because the developer of knowledge transmission missing, difficult to understand and very easy to mention the code quality improvement, can only become a training ground for advocates realization of personal value promotion.
personal idea
Personally, I think, domain-driven design methods, response to it as a solution to a complex problem, indeed worthy of sustained attention to their business, but is there a way to convenient way, participants will be able to more quickly in such a good methodology product development process mastered, a more efficient application process it, I think the following is a little according to some discussion and learning process, the formation of hope that we can bring a ray of inspiration.
1, how to start changing the culture? This is a question from "instantiation demand" raised in the author's intention is that to practice TDD, the need for cultural change, perhaps the same is true in fact practice DDD. Conway's law states that: an organization to come up with a technical solution design, in fact, is the embodiment of an organization's communication. Your organization is ready to start really put to the test this idea yet? This is a problem.
2, make sure you get the support of management. This is also from the "instantiation demand" in the original words, there is no doubt that if the lack of recognition and support of management, process changes the probability of success is almost zero.
3, agility forget, forget the field of drive, forget about the concept. Because domain-driven design approach may seem obscure, easy to drive organizational practice areas people misunderstand or academic dogmatism, which is reflected in: organizers prefer to use standard terminology given by experts in the field-driven design the method of interpretation and lack of actual business combination forms. I personally believe that the application process in order to better promote the domain-driven design should not be limited to dogmatism, not too much attention to the concepts, frameworks or automated tools, but to drive the design process areas, interpreted as a discovery demand, explain correlation collected examples, test design, and forming a self-explanatory code development process between the demand.
4, from a simple project to start small projects and explore the establishment of an effective method. From a clear business structure, easy to subdivide the project application scenarios and operational activities of the departure, to avoid falling into the process of large projects it is difficult to control the border, and large project implementation if not better, just out of control. Some netizens said that due to the extreme uncertainty of project requirements, so he felt the need to introduce domain-driven design method to solve this problem, I personally think that such an approach will only lead to more projects out of control, especially in a learning ability is not good organization to carry out the field-driven design practices, and we are all under the premise of this theory little knowledge of.
5, refining a unified language from the language of the product. Axure popular software, so that by the prototype document visualization needs of this expression into the mainstream. Prototype Language and close to the height of demand, but also to facilitate the product development team from a unified language.
6, a glossary available products. From unified language, form can guide the programming of the glossary, and the formation of bilingual corresponding to the table, can easily provide regular variable named for the development process, especially many developers themselves level of English is not particularly good, if a such rules might be able to bring a lot of convenience for the development of the code.
7, use case diagrams extracted from a unified language and requirements. According to Zhang Yi teacher to say, use cases or user stories should meet 6w features, you can try to stand in thinking about this issue with the angle example:
- In the end who is the user? Who needs to perform the role of this activity in the end is?
- Why do we need search function?
- To find exactly what kind of content?
- Why do I need to understand the tasks assigned to the case?
8，从用例图和业务流程中识别限界上下文。没必要一开始就采用四色建模法，采用比较简单的领域场景分析的用例分析方法进行分析，同样是不错的选择，例如从分析业务活动间的语义相关性，也是一种值得尝试的方法。
总结
人生三境界：看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水。大概技术领域也同样如此。
回到一个古老的问题，有人问：如何给一个变量命名，词穷了怎么办？专家的回答是，按领域驱动设计的方法对变量进行命名。这就是实践领域驱动设计的大师高论，已经到了看山还是山的地步。而普通开发者们，总是看了几篇领域驱动设计的文章，就会以为嗯，我遇到的这些问题，用领域驱动能解决，然后，就陷入一堆概念之中不可自拔。
实践是检验真理的唯一标准，唯有真的使用一个项目开始实践，才能真正体会领域驱动设计的精髓。领域驱动设计思想，是一种充满魅力的软件理论方法，然而要把这套理论真的用起来，依然需要经历一个从新手到高级新手，再到胜任者、精通者和专家的学习过程。本文也同样属于一位处于新手村学习者的个人见解，班门弄斧，期待能抛砖引玉，措辞多有不当，还望海涵。
参考资料：1、Eric Evans《领域驱动设计·软件核心复杂性应对之道》
2、张逸 《GitChat讲座：领域驱动设计实战》
3、Gojko Adzic《实例化需求》