100 lines
10 KiB
Markdown
100 lines
10 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
002 「战略篇」开篇词：领域驱动设计，重焕青春的设计经典
|
||
专栏背景
|
||
|
||
领域驱动设计确实已不再青春，从 Eric Evans 出版的那本划时代的著作《领域驱动设计》至今，已有将近十五年的时间，在软件设计领域中，似乎可以称得上是步入老年时代了。可惜的是，对于这样一个在国外 IT 圈享有盛誉并行之有效的设计方法学，国内大多数的技术人员却并不了解，也未曾运用到项目实践中，真可以说是知音稀少。领域驱动设计似乎成了一门悄悄发展的隐学，它从来不曾大行其道，却依旧顽强地发挥着出人意料的价值。
|
||
|
||
直到行业内吹起微服务的热风，人们似乎才重新发现了领域驱动设计的价值，并不是微服务拯救了领域驱动设计，是因为领域驱动设计一直在坚硬的生长，然而看起来，确乎因为微服务，领域驱动设计才又焕发了青春。
|
||
|
||
我从 2006 年开始接触领域驱动设计，一开始我就发现了它的魅力并沉迷其间。从阅读 Eric Evans 的《领域驱动设计》入门，然后尝试在软件项目中运用它，也取得了一定成效。然而，我的学习与运用一直处于摸索之中，始终感觉不得其门而入，直到有机会拜读 Vaughn Vernon 出版的《实现领域驱动设计》一书，并负责该书的审校工作，我才触摸到了领域驱动从战略设计到战术设计的整体脉络，并了解其本质：领域驱动设计是一个开放的设计方法体系。
|
||
|
||
即使如此，许多困惑与谜题仍然等待我去发现线索和答案。设计总是如此，虽然前人已经总结了许多原则与方法，却不能像数学计算那样，按照公式与公理进行推导就一定能得到准确无误的结果。设计没有唯一的真相。
|
||
|
||
即使如此，如果我们能够走在迈向唯一真相的正确道路上，那么每前进一步，就会离这个理想的唯一真相更近一步，这正是我推出这门课的初衷。也并不是说我贴近了唯一真相，更不是说我已经走在了正确道路上，但我可以自信地说，对于领域驱动设计，我走在了大多数开发人员的前面，在我发现了更多新奇风景的同时，亦走过太多荒芜的分岔小径，经历过太多坎坷与陷阱。我尝试着解答领域驱动设计的诸多谜题，期望能从我的思考与实践中发现正确道路的蛛丝马迹。我写的这门专栏正是我跌跌撞撞走过一路的风景拍摄与路径引导，就好似你要去银河系旅游，最好能有一本《银河系漫游指南》在手一样，不至于迷失在浩瀚的星空之中，我期待这门专栏能给你带来这样的指导。
|
||
|
||
专栏框架
|
||
|
||
本专栏是我计划撰写的领域驱动设计实践系列的第一部分内容（第二部分内容是领域驱动战术设计实践，后面陆续更新），其全面覆盖了领域建模分析与架构设计的战略设计过程，从剖析软件复杂度的根源开始，引入了领域场景分析与敏捷项目实践，帮助需求分析人员与软件设计人员分析软件系统的问题域，提炼真实表达的领域知识，最终建立系统的统一语言。同时，本专栏将主流架构设计思想、微服务架构设计原则与领域驱动设计中属于战略设计层面的限界上下文、上下文映射、分层架构结合起来，完成从需求到架构设计再到构建代码模型的架构全过程。
|
||
|
||
本专栏分为五部分，共计 34 篇。
|
||
|
||
开篇词：领域驱动设计，重焕青春的设计经典
|
||
|
||
第一部分（第 3~7 篇）：软件复杂度
|
||
|
||
|
||
领域驱动设计的目的是应对软件复杂度。本部分内容以简练的笔触勾勒出了领域驱动设计的全貌，然后深入剖析了软件复杂度的本质，总结了控制软件复杂度的原则，最终给出了领域驱动设计应对软件复杂度的基本思想与方法。
|
||
|
||
|
||
第二部分（第 8~12 篇）：领域知识
|
||
|
||
|
||
领域驱动设计的核心是“领域”，也是进行软件设计的根本驱动力。因此，团队在进行领域驱动设计时，尤其需要重视团队内外成员之间的协作与沟通。本部分内容引入了敏捷开发思想中的诸多实践，并以领域场景分析为主线讲解了如何提炼领域知识的方法。
|
||
|
||
|
||
第三部分（第 13~22 篇）：限界上下文
|
||
|
||
|
||
限界上下文是领域驱动设计最重要的设计要素，我们需要充分理解限界上下文的本质与价值，突出限界上下文对业务、团队与技术的“控制”能力。
|
||
提出了从业务边界、工作边界到应用边界分阶段分步骤迭代地识别限界上下文的过程方法，使得领域驱动设计的新手能够有一个可以遵循的过程来帮助识别限界上下文。
|
||
剖析上下文映射，确定限界上下文之间的协作关系，进一步帮助我们合理地设计限界上下文。
|
||
|
||
|
||
第四部分（第 23~30 篇）：架构与代码模型
|
||
|
||
|
||
作为一个开放的设计方法体系，本部分引入了分层架构、整洁架构、六边形架构与微服务架构等模式，全面剖析了领域驱动设计的架构思想与原则。
|
||
结合限界上下文，并针对限界上下文的不同定义，对领域驱动的架构设计进行了深度探索，给出了满足整洁架构思想的代码模型。
|
||
|
||
|
||
第五部分（第 31~36 篇）：EAS 系统的战略设计实践
|
||
|
||
|
||
给出一个全真案例——EAS 系统，运用各篇介绍的设计原则、模式与方法对该系统进行全方位的战略设计，并给出最终的设计方案。
|
||
|
||
|
||
本专栏并非是对 Eric Evans《领域驱动设计》的萧规曹随，而是吸纳了领域驱动设计社区的各位专家大师提出的先进知识，并结合我多年来运用领域驱动设计收获的项目经验，同时还总结了自己在领域驱动设计咨询与培训中对各种困惑与问题的思考与解答。本专栏内容既遵循了领域驱动设计的根本思想，又有自己的独到见解；既给出了权威的领域驱动知识阐释，又解答了在实践领域驱动设计中最让人困惑的问题。
|
||
|
||
为什么要学习领域驱动设计
|
||
|
||
如果你已经能设计出美丽优良的软件架构，如果你只希望脚踏实地做一名高效编码的程序员，如果你是一位注重用户体验的前端设计人员，如果你负责的软件系统并不复杂，那么，你确实不需要学习领域驱动设计！
|
||
|
||
领域驱动设计当然并非“银弹”，自然也不是解决所有疑难杂症的“灵丹妙药”，请事先降低对领域驱动设计的不合现实的期望。我以中肯地态度总结了领域驱动设计可能会给你带来的收获：
|
||
|
||
|
||
领域驱动设计是一套完整而系统的设计方法，它能带给你从战略设计到战术设计的规范过程，使得你的设计思路能够更加清晰，设计过程更加规范。
|
||
领域驱动设计尤其善于处理与领域相关的高复杂度业务的产品研发，通过它可以为你的产品建立一个核心而稳定的领域模型内核，有利于领域知识的传递与传承。
|
||
领域驱动设计强调团队与领域专家的合作，能够帮助团队建立一个沟通良好的团队组织，构建一致的架构体系。
|
||
领域驱动设计强调对架构与模型的精心打磨，尤其善于处理系统架构的演进设计。
|
||
领域驱动设计的思想、原则与模式有助于提高团队成员的面向对象设计能力与架构设计能力。
|
||
领域驱动设计与微服务架构天生匹配，无论是在新项目中设计微服务架构，还是将系统从单体架构演进到微服务设计，都可以遵循领域驱动设计的架构原则。
|
||
|
||
|
||
专栏寄语
|
||
|
||
没有谁能够做到领域驱动设计的一蹴而就，一门专栏也不可能穷尽领域驱动设计的方方面面，从知识的学习到知识的掌握，进而达到能力的提升，需要一个漫长的过程。所谓“理论联系实际”虽然是一句耳熟能详的老话，但其中蕴含了颠扑不破的真理。我在进行领域驱动设计培训时，总会有学员希望我能给出数学公式般的设计准则或规范，似乎软件设计就像拼积木一般，只要遵照图示中给出的拼搭过程，不经思考就能拼出期待的模型。——这是不切实际的幻想。
|
||
|
||
要掌握领域驱动设计，就不要被它给出的概念所迷惑，而要去思索这些概念背后蕴含的原理，多问一些为什么。同时，要学会运用设计原则去解决问题，而非所谓的“设计规范”。例如：
|
||
|
||
|
||
思考限界上下文边界的划分，实际上还是“高内聚、低耦合”原则的体现，只是我们需要考虑什么内容才是高内聚的，如何抽象才能做到低耦合？
|
||
是否需要提取单独的限界上下文？是为了考虑职责的重用，还是为了它能够独立进化以应对未来的变化？
|
||
在分层架构中，各层之间该如何协作？如果出现了依赖，该如何解耦？仍然需要从重用与变化的角度去思考设计决策。
|
||
为什么同样遵循领域驱动设计，不同的系统会设计出不同的架构？这是因为不同的场景对架构质量的要求并不一样，我们要学会对架构的关注点做优先级排列，从而得出不同的架构决策。
|
||
|
||
|
||
我强烈建议读者诸君要学会对设计的本质思考，不要只限于对设计概念的掌握，而要追求对设计原则与方法的融汇贯通。只有如此，才能针对不同的业务场景灵活地运用领域驱动设计，而非像一个牵线木偶般遵照着僵硬的过程进行死板地设计。
|
||
|
||
分享交流
|
||
|
||
我们为本专栏付费读者创建了微信交流群，以方便更有针对性地讨论专栏相关问题。入群方式请到第 5 篇末尾添加小编的微信号。
|
||
|
||
阅读文章过程中有任何疑问随时可以跟其他小伙伴讨论，或者直接向作者提问（作者看到后抽空回复）。你的分享不仅帮助他人，更会提升自己。
|
||
|
||
|
||
|
||
|