进城务工人员小梅 近期对DDD进行了学习和尝试性地使用，抽空结合现有的浅显认知进行了初步总结。本文中我针对DDD的主要观点包括：
一、什么是DDD（Apache ISIS中的理解）
二、DDD是计算机领域不可或缺的一部分
三、理解DDD需要首先学习有关DDD的部分基础知识
四、理解DDD需要较深的专业底蕴和一线企业级编码/全流程经验
五、DDD是接近计算机领域“真相”的必由之路
六、DDD是联结计算机技术与计算机工程的桥梁
七、DDD是所有计算机行业从业人员应该具备的意识
八、DDD引入了新的职业角色“领域建模专家”
九、DDD是成为“设计师”和“架构师”的必然要求
十、DDD是计算机从业人员的最终出路之一
十一、DDD符合终身学习的价值理念及事物的发展规律
十二、DDD是中国高校计算机教育教学体系中的悲剧性缺失
十三、DDD的某些不足
其中，上述观点中的DDD在一定程度上也可替换为其他类似的某种高层建模方法论。本文只谈个人对DDD的理解和定位，暂时不谈具体落地，有关DDD实现的理解后续单独总结。正如本文第三、四条所述，和DDD整体所呈现的，懂/能懂/愿意懂/愿意认可/愿意部分认可和借鉴的人自然会懂、不懂/不能懂/不愿意懂/不愿意认可的人则说什么也没用。
当Evans的DDD看到一半的时候，我不禁画下了下面这张思维导图：
计算机领域导图
我突然有了一种感觉：有关所谓“计算机领域”这个大概念的拼图似乎更加完整了，剩下的就最终可以落到选择的问题了；按这种逻辑，诸如“究竟是否要投入更多地精力去学习算法乃至某些数学”这样的问题同样也就应该变成了选择之后的配套辅助手段。请注意，上图中只列出了部分内容，颗粒度不同，有粗有细，主要是为了定位DDD所处的位置，仅为导图，不要过度纠结。
很久以来，除从事基本的“领域开发”外（业务系统开发），因为畏惧/不擅长数学和算法，我一直乐于和致力于从事“软件基础设施”类的工程性项目的开发，即试图用技术的组合来解决实际的问题，“让别人在我写的基础框架内、利用我写的基础代码和我选定的架构编码”也是我一直以来的口号和乐趣所在，做Solving Problem的人。但是，尽管如此也因为如此，有几个问题一直困扰着我：
①计算机专业学习的相对最优路径应该是什么；
②计算机行业从业人员相对最优的最终职业出路应该是什么；
③所谓的设计师和架构师究竟指的是什么、需要做什么、需要做到什么；
我想，DDD为回答上述这三个问题提供了一些切实的思路和方案，也是要在此进行总结的原因。
一、什么是DDD（Domain-Driven Design）
Apache顶级项目ISIS的文档中对DDD有一段浅显但尚有一定概括性的介绍，尽管ISIS为Apache顶级项目，但国内关于其的资料甚少，中文文档更是没有，因此我在此将其翻译成了中文（对应Core Concepts一章中的Philosophy and Architecture一节，链接为http://isis.apache.org/guides/ugfun/ugfun.html），并根据行文的具体需要对其中的部分内容进行了删减和调整，作为对DDD定义的描述，总结如下。
毫无疑问，我们开发人员喜欢应对“理解和部署复杂技术”所带来的挑战。但是，“理解业务领域本身的细微差别和微妙之处”同样是一个巨大的挑战，而且也许还更加重要。如果我们致力于理解并解决这些微妙之处，那么应该可以构建出更好、更简洁、更可维护的软件（better, cleaner, and more maintainable software），从而为我们的利益相关者更好地工作。毫无疑问，这才是我们的利益相关者（stakeholder）所关注的。
尽管Eric Evans的《领域驱动的设计》中大部分的想法并非原创，但他将这些想法进行了融合并展示了如何使用面向对象的技术来开发丰富、深入、有洞察力且最终有用的业务应用程序（rich, deep, insightful, and ultimately useful business applications）。
领域驱动设计的核心思想有两点：
1.统一语言（ubiquitous language），让整个团队（领域专家和开发人员）更透明地使用领域模型进行交流；
2.模型驱动设计（model-driven design），在代码中以一种非常直接的方式捕获领域模型。
1.1 统一语言（Ubiquitous Language）
IT行业深受项目失败的困扰已经不是什么秘密了。通常，实现系统需要的时间比预期的要长，而且当系统被最终实现时，它们也并没有解决实际的需求。
我们IT行业的从业人员多年来一直在尝试各种方法来解决这个问题。使用瀑布式开发的方法论，我们要求在开始任何其他工作之前先完全和精确地把需求写出来。或者，使用敏捷开发的方法论，我们认识到需求很可能会发生变化，并寻求通过反馈循环来增量式地交付系统来完善我们的实现。
先抛开方法论不谈。在本质上，最重要的实际是需要系统的领域专家（即业务）和实现系统的技术人员之间的沟通。如果这两方对所需要的东西没有共同的理解，那么就基本不可能交付可用系统。
传统上，业务分析师（business analysts）负责弥补这个问题；他们充当了领域专家和开发人员之间的解释器。不过，这仍然涉及了两种（甚至更多种）语言，导致验证“正在构建的系统是正确的”非常困难。如果分析师错误地理解了一个需求，那么领域专家和应用程序开发人员都不会发现这一点，直到应用程序第一次被演示（这还算好的）或者一个用户在应用程序被部署到生产环境中发出警报（更糟糕的情况）。
与其尝试在一种业务语言（business language）和一种技术语言（technical language）之间进行翻译（translate），不如通过DDD让业务人员和开发人员使用相同的术语来创建同一个领域模型（domain model）。这个领域模型识别了领域的相关概念、它们之间的关系及最终的职责。这个单一领域模型为我们的系统提供了统一语言的词汇表。
通过使用领域模型的概念作为主要的沟通手段，可以在领域专家和开发人员之间构建一种通用语言。在演讲、图表、文档和讲PPT时都可以使用术语。如果一个想法不能用领域模型的概念来表达，那么就应该回顾并扩展模型。寻找并消除模棱两可和不一致的地方。
创建一种统一语言依赖于参与系统开发的每个人通过模型提供的词汇表来表达他们希望要做的事情。如果做不到，那么我们的模型就是不完整的。寻找缺失的词汇依赖于我们对正在被建模的领域的理解。
这听上去似乎只不过是坚持让开发人员在与业务人员对话时不使用技术术语；但实际上仅仅是统一语言概念的一小部分。统一语言要求开发人员努力工作以理解问题领域，同样也要求业务人员精准地命名和描述这些概念。毕竟，最终开发人员必须用计算机编程语言表达这些概念。
此外，“领域专家”可能不是一个具体的人，而是一群同质化的人，这群人通常可能来自不同的业务部门。即便我们不是在建立一个计算机系统，帮助领域专家标准化他们自己的术语也有很大的价值。同是“客户”，对市场部门、销售部门和售后部门的而言可能就是不一样的概念（分别是prospect、customer和contract）是一样的吗?
使用精准的统一语言也帮助我们框定系统的范围。大多数业务流程是碎片化的，而且常常被定义得很糟糕。如果领域专家对一个业务流程认识清晰，那么就利于实现自动化，即包括在系统范围内。但是，如果领域专家都很难定义一个业务流程，那么则最好将其排除在系统外。毕竟，人类比计算机更能处理模糊的情况。
因此，如果开发团队（业务和开发人员一起）不断地探索来构建统一语言，那么随着领域细节的不断被发现，领域模型会自然变得更加丰富。与此同时，业务领域专家的知识（knowledge ）也会随着以前被忽视的边缘条件（edge condition）和自相矛盾之处（contradiction）而不断深化。
1.2 模型驱动设计（Model-Driven Design）
我们使用统一语言来构建了一个领域模型。但是我们要怎么使用领域模型呢？
在IT行业所尝试过的各种各样的方法中，很多方法都提倡过生成独立的分析模型（ analysis model）和实现模型（implementation model）。一个例子（从20世纪中期开始）就是OMG’s Model-Driven Architecture ( MDA) 的出现，它提出了平台独立的模型（platform-independent model，PIM）和特定于平台的模型（platform-specific model，PSM）。
这是完全扯淡的！如果我们使用我们仅仅使用统一语言来构建了一个高级的分析模型，那么我们又重新制造了沟通的鸿沟。领域专家和业务分析师会只关注分析模型，而开发人员只关注实现模型。除非这两者之间的映射是完全机械的，否则这两者还是会出现不可避免的分歧。
我们所说的模型究竟是什么意思呢？对一些人来说，这个术语会让人联想到UML类或序列图之类的东西。但它们不是一个模型，它们只是一个模型某些方面的可视化表现。一个领域模型实际上是一组相关的概念的，要识别它们、命名它们并定义它们之间的关系。模型中有什么取决于我们的目标是什么。我们并非要寻找一个简单的模型来反映现实世界中的一切。相反，我们只是想要对现实世界进行一定的抽象或简化，然后利用这种抽象或简化为我们服务。一个模型无法衡量对错，只是有用的程度不同。
要让统一语言产生价值，编码它的领域模型就必须对软件的设计（特别是软件的实现）有一个直接且书面化的表示。软件设计应该由这个模型驱动，我们应该有一个模型驱动的设计。对于软件，必须有一种直接且书面化的方式来表达领域模型。模型应该平衡两个需求：形成开发团队的统一语言，并在代码中表达模型。修改代码就意味着修改模型，优化模型同样需要修改代码。
在这里，“设计”一词可能会让人误解；有些人可能觉得是设计文档、设计图表或用户接口（UX）设计。但是，我们所指的“设计”实际是一种组织领域概念的方式，这种方式反过来又会指导我们在代码中组织“设计”的表示。
幸运的是，使用诸如Java这样的面向对象语言，这是相对容易做到的；毕竟面向对象是基于建模范式的。我们可以使用类和接口来表达领域概念，也可以使用关联来表达这些概念之间的关系。
二、DDD是计算机领域不可或缺的一部分
可以认为，正是“存在大量的领域和领域流程需要进行信息化和持续的信息化支撑”带来了整个计算机行业的繁荣并构成了行业之所以存在的根本条件，而“信息化”的本质就是“领域软件的开发和持续演进”。因此，DDD作为一种针对“领域软件的开发和持续演进”的重要领域建模方法论也就必然地成为了计算机领域不可或缺的一部分。
首先，最终交付符合业务领域需求和利益相关者/干系人要求的，具有柔性、弹性、可维护性等的系统是计算机行业之所以存在的根本（此处特指软件系统，但实际应该是更大的概念），DDD为在复杂领域中开发符合上述要求的软件系统提供了重要的指导思想。众所周知，千奇百怪的不同垂直领域和源于日益激烈外部竞争所导致的剧烈需求变更等为开发出符合要求的系统制造了巨大的困难，如果不能解决来自领域本身、用户活动和用户业务等方面的领域复杂性，基础技术架构再好也无济于事；同时，由于开发人员缺乏对具体业务领域的高层抽象和有预见性的建模，往往导致生硬、僵化、难以修改、问题频发等悲剧性系统的出现，半途而废的项目时有发生，并最终对成本、质量、进度等重要项目管理因素造成了严重冲击。开发能够传递真正业务价值（包含快速适应变更、支撑在同业竞争中脱颖而出等概念）的软件和开发普通的软件是完全不同的，对于DDD而言：
①通过统一语言和模型的引入，有利于开发团队（包括领域专家、开发人员等）充分地消化和吸收散落在在不同人和文档中的知识，避免专职“需求分析人员”充当领域专家和开发人员之间的“翻译”，在使用公共语言并形成贯穿整个实现过程的反馈闭环中充分利用人类的语言天性，提供超出原有文档、图表、UML等表达能力的稳定和共享的交流，填补领域专家和开发人员之间的鸿沟，在解决信息超载问题的同时，充分保护和共享知识，在反复对模型的走查中暴露模型中存在的缺点，替换不恰当的术语，识别传统除实体和过程行为外更加重要的隐含概念（如大量的规则、约束条件及过程等），最终精化出足够灵活的、蕴含丰富知识的、对领域具有深刻表达的模型。
②通过领域对象的引入，有利于扭转在复杂领域开发中错误的面向过程建模和面向过程编码思维。近年来，尽管编程语言发生了不断地持续演进，从C等典型的面向过程语言演进到了Java等典型的面向对象语言；但是，大量的开发人员在使用Java等面向对象语言时仍然使用了反映自然过程式编程风格的贫血模型，仅仅在迫不得已的重构或显而易见时才使用少量继承、接口、抽象类等面向对象的抽象机制，构造出的是以数据为中心的模型，而模型又最终退化为数据结构，所谓的对象根本不是对象而仅仅是一个数据的容器！遍布项目代码中的是大量仅暴露了公共属性的贫血对象，和堆砌的、僵化的、分散的、过程性、易失忆的逻辑，这些逻辑中包含了大量难以跟踪和修改的规则判断等业务流程逻辑。在使用关系数据库作为数据持久化手段时，由于现实世界和实体关系模型之间的天然阻抗，开发者往往还需要花费大量精力处理对象和数据库实体之间的映射和CRUD，甚至将库表结构设计与领域建模设计本末倒置。集成的、模型驱动的系统所提供的价值是使用过程逻辑拼凑起来的系统所无法提供的，DDD通过领域对象的引入，坚决摒弃贫血模型，强调富有行为的对象的重要性，让领域对象表明领域模型中的概念和模型与代码的一致性，从而有利于扭转在复杂领域开发中错误的面向过程建模和面向过程编码思维，充分利用面向对象语言所带来的抽象能力。
③通过模式、战术建模及战略建模等概念的引入，有利于让开发人员站在比过程编程及设计模式这类编码级技巧高得多的角度和意识形态层面进行思考，充分利用大量前人对分析模式、设计模式、集成模式等等的大量总结和参考，督促开发人员始终把“将领域专家的思维模型转换为有用的业务模型”放在首位，真正地做到“设计在前”，站在巨人肩膀上优雅地综合运用分析模式、设计模式、集成模式、新兴基础设施等等有利武器应对复杂领域中繁杂的规则和流程等业务逻辑，而不是拿到需求分析人员提出的原始需求就开始下意识地思考在数据库表结构之间的映射。
其次，之所以说“领域开发”是计算机领域之所以存在的根本，可以从计算机行业从业人员的数量分布中证明。纵观周围，常见涉及正向软件开发的一般有这么几类人（不考虑逆向及逆向开发，也不考虑网络等一般与开发不直接相关的）：
①算法类：这类人一般热衷于ACM和OJ，喜爱数学而且还积极学习图论、计算几何等内容，很多是进入大学迷茫过后基于带有一定随机性而选择算法并延续至职业生涯选择的，对应算法工程师等，一般具有鲜明的特征；
②基础设施类：这类人又分为三种，分别对应上述思维导图中的软件基础设施和算法基础设施：一种主要致力于开发或二次开发相对独立的基础设施类的库或产品，往往与开源社区相关，聚焦于解决某一特定领域的特定需求，如聚焦于高性能NIO的Netty、分布式协调的ZooKeeper、内存键值存储的Redis等库和产品；另一种往往由算法工程师们发起，致力于某些算法的工程化应用，如机器视觉方面的OpenCV、机器学习方面的TensorFlow、自然语言处理方面的word2vec等等；再一种则致力于利用上述的基础设施类的库或产品和算法基础设施，通过进行一定的封装、整合和深入的定制等，构建更高层次的企业级基础设施平台，这类基础设施平台往往立足一家或一类企业需求，并服务于构建在其上的企业级业务应用（或直接作为云化产品销售，服务于开放第三方），如分布式Web中间件、分布式消息中间件、分布式服务治理、大数据平台、机器学习平台、业务应用开发框架等等；
③一般开发类：这类人占据了IT开发人员的绝大部分，这类人之所以存在也是计算机行业之所以存在的主要原因（有大量的领域和领域流程需要进行信息化和持续的信息化支撑），对应日常所说的各类开发工程师（如软件开发工程师等），通常基于第二点中提到的基础设施平台开发企业级业务应用，按照“是单纯从事应用开发还是除从事单纯的应用开发外还会对某些功能或模块进行封装以供他人使用”的维度主要可以分为两种：一种是单纯从事劳动力输出进行重复低端编码开发人员，对专业基础知识掌握欠佳、对编码工作的理解不高、对需求的抽象能力较差，通常为非一线高校科班出身，只能进行一般概念的过程性编码；另一种通常为一线高校科班出身，对专业基础知识掌握尚可、通过在工作中的工程化编码实践等对编码工作建立了一定的理解、通过在工作中与对抽象需求也具有了一定的认知、除一般概念的过程性编码外还会对某些功能或模块进行封装以供他人使用甚至还可进行更高层次的抽象，这类人由于随机或选择原因没有从事第二条中的基础设施类开发工作，但其中的某些可能会在某些随机时由于机缘或自身选择变成从事基础设施类开发人员中的第三种，成为企业构建基础设施平台的开发人员；
④全栈开发类：全栈是一个具有鲜明阶段性的词汇：一方面，在快速学习阶段，全栈有利于个体通过实际参与包括前后/台在内的开发投产运维全流程等快速建立对计算机领域（和所在业务领域）的整体认识和意识感觉；另一方面，在职业生涯的关键成长阶段，全栈不利于个体在某一个领域进行深耕细作，个体需要在合理的时点和借助适当的机缘退出实际的一线全栈开发，并以坚强的内心进行部分放弃，否则在后续跳槽时能否拿到期待的薪酬将是问题。全栈的概念是随着NodeJS等JavaScript占领全世界的趋势而逐渐出现的，在传统意义上和日常工作中，大部分人认为全栈只包括广义的前后端开发，但实际上全栈也应该包括了对嵌入式软硬件、逆向工程及安全的认知和理解。可以认为，从事全栈开发的人通常是学习能力、学习意愿和学习等均较强的敏捷性个体，全栈在一定程度上也应该是成为架构师的必要阶段。因此，全栈的鲜明阶段性也就体现在某个转折阶段后，全栈不再是褒义词而会变成贬义词。
这样，在IT行业从业人数占据绝大多数的“一般开发”人员证明了“领域开发”之所以说“领域开发”是计算机领域之所以存在的根本，可以从计算机行业从业人员的数量分布中证明。
总之，千奇百怪的领域对“信息化和持续的信息化支撑”是计算机行业之所以存在的根源，“领域开发”作为“信息化”的实质又面临领域复杂性所带来的巨大挑战，而DDD作为复杂领域建模的重要方法论为交付符合业务领域需求的具有柔性、弹性、可维护性等的系统提供了重要现实指导和参考。我们应该意识到，开发者不应该只是热衷于技术，而是应该将眼界放得更宽。有才能的软件工程师通常认为纯粹的技术任务是最有趣、最具挑战性的，但领域驱动设计展现了一个同样富有挑战性甚至更具挑战性的新领域。因为不管使用什么技术，我们的目的都是提供业务价值。因此，DDD是计算机领域不可或缺的一部分。
三、理解DDD需要首先学习有关DDD的部分基础知识
DDD首先并不是关于技术的，而是关于讨论、聆听、理解、发现和业务价值的。DDD作为高层建模方法论的一种，对其的理解依赖于初步的背景知识和一定的先验基础。我们经常看到有的从业者在乍接触到DDD时有意或无意地排斥诸如统一语言、战术建模、战略建模、柔性设计等看似玄学的术语。然而，这些从业者忽略了DDD本身也属于一个领域的事实。要想理解它就必须像我们理解所有其他业务领域一样以学习和了解的心态去试着理解并接受。请问，DDD中的’统一语言‘与金融领域的’附保贴函商业承兑汇票质押融资‘有什么本质性的区别么？它们都只不过是两个领域中的特定术语罢了。
“码农”是一个自黑的褒义词。码农们的双手具有无穷的创造力，他们对周围世界有着异于其他行业从业人员的敏锐观察力，乐于终身学习和快速学习，并具有发现和抽象问题本质规律特征的思维习惯。对一个优秀的码农而言，能否快速建立对某个领域具有一定深度的理解往往在于其主观能动性的选择，关键在于他们是否选择投入精力且乐于接受。DDD作为方法论，不是完全理性的教条主义，需要结合践行者的先验和感性根据具体情况因地制宜，普遍习惯“固定输入得到固定输出”模式的码农需要充分接受和理解这方面的不确定性。即便在实践中充满困难，但DDD绝非是不能落地的玄学概念。因此，只要秉持着学习其他领域同样的开放心态，首先耐心学习有关DDD的背景知识，是应该能够逐步感受和理解DDD的强大之处的。
四、理解DDD需要较深的专业底蕴和一线企业级编码及全流程经验
就像DDD的统一语言具有鲜明的感性特点一样，DDD同样具有鲜明的感性特点，只有具备了一定的专业底蕴和实际工程实践后才能理解DDD。
首先，虽然DDD的统一语言强调充分利用人类的语言天性，在团队的不断交流中自然而然地让团队成员通过统一语言的形式学习、纠正和优化其他项目成员所交叉呈现出的知识，通过大量的讨论、参考资料、引用标准、查阅词典等对统一语言进行改进，不断修改和纠正发现不恰当的术语和分歧；但是，这个过程一方面要求一个领域专家向开发人员和其他领域专家高效率地传递知识，另一方面也同样要求开发人员能够凭借较深的专业底蕴和建立在专业底蕴之上的敏锐洞察力向领域专家高效精准地传递软件开发方面的知识，让领域专家快速建立对软件开发的感性认知进而为软件设计做出贡献，并在建模时作出果断的判断。然而，这依赖于开发人员的专业底蕴和实践经验：一个低级开发人员和一个高级开发人员能够简明扼要又一语中的地向领域专家解释技术问题和呈现技术感觉的能力显然是截然不同的。
其次，DDD强调模型与代码实现的统一，对模型的修改必须反映在代码实现上、对代码实现的修改同样必须反映在模型中。这样，在建模时白板讨论和走查的过程中也就必然要求开发人员以敏锐的直觉洞察模型与代码实现之间对应的恰当性，根据现有技术架构、系统架构等快速根据对模型的实现方式、实现难度、实现可行性和周期等进行调整，这是同样依赖于专业底蕴和实践经验，往往是低级开发者所不可能具备的。
再次，尽管多年的开发经验并不会教会开发人员向领域专家倾听和学习的能力，但开发经验的缺乏会导致开发人员难以实际感受领域开发所面临的艰难困境和核心问题，也不足以支持他们体会“模式”和“领域建模”的必要性，进而更加不能体味DDD的强大和良苦用心。通常，只有在真正吃过亏之后才能觉悟，而低级开发人员往往缺乏对“领导者责任”的认知，不能设身处地得感受TeamLeader/项目经理或更高层级领导所面临的交付压力，也不能理解其所开发出产品在交付后对后续运维、运营等全流程可能产生的影响，进而更加不可能理解DDD为解决上述问题提供的可能。
理解DDD既依赖于需要首先学习有关DDD的部分基础知识，又依赖于需要较深的专业底蕴和一线企业级编码及全流程经验。我认为，在相当程度上，拒绝接受DDD或类似方法论的想法是可笑的，即便DDD在实践中面临着诸多的问题，但不能理解或难以理解DDD的根源应该来源于开发者自身对“领域开发”乃至计算机专业领域全景的认知缺失，而与DDD本身无关；正如Dave Collins的评价，DDD是站在巨人肩膀上所沉淀下来的亘古不变的智慧，在流行的方法论都沦为明日黄花后，它依然光华璀璨 。
五、DDD是接近计算机领域“真相”的必由之路
很多人活不明白，而活得明白的人总是需要一个“支点”。有些人的支点是责任感，他们因为具有责任感而成功，亦被责任感所绑架，不管是为家庭、为团队、为公司还是为社会；有些人的支点是“惯性”，他们因为天性和教育而在活明白前就已经被驱动到了一个必须依照优秀的惯性而不断向前的位置；有些人的支点是“解决问题”，他们被培养出来发现问题的眼睛，因为问题而生，而为解决问题而死；有些人的支点则是“探究真相”。
“求真务实”，对真相的探索是人类社会向前进步的源动力，科学的真相让我们对客观世界具有了正确的认识，同时赋予了我们探索未知世界的工具，改变了我们观察世界的方式方法及行为模式。人们不断地确认、选择、实践、创造，并不断追寻存在的意义，这就是我们的生活。人类智慧的发展体现在创造工具的思维及从中感受智慧的乐趣上。我们被教育探索真相、最终走向真理的过程，就是不断地摆脱各种各样束缚的一种思想探索。理解业务领域本身的细微差别和微妙之处，开发能够传递真正业务价值，为利益相关者创造价值的领域软件正是计算机领域永恒的真理之一：
首先，DDD通过明确对普通软件和领域软件的区分，让我们对计算机领域这一客观世界有了更加正确的认识。在计算机领域中，我过去一直认为嵌入式和逆向工程也是接近计算机领域“真相”的必由之路。早2007年上大二时，我便意识到嵌入式在计算机领域中地位，甚至花费不菲的学费去参加培训机构有关嵌入式的培训，直到研究生甚至选择了嵌入式作为方向，虽然不软不硬但嵌入式的软硬结合又让我看到了整个世界都是一堆零件而已，所带给我对整个计算机世界的认识也是受用终身的；在逆向工程方面虽然我没有过度地深入，但同样也曾经进行过很多“不足为外人道也，也不能为外人道也”的工作，所带给我对整个计算机世界的认识同样也是受用终身的。然而，即便如此，即使我自认为知识体系相对全面，心中却一直深深地不安，始终隐隐地感觉缺了什么东西，但高度不够不能自我发现、身边也无高人点拨，这种不安像数学和算法的弱点一样让我惶恐且难以平衡。正是DDD让我明白了这块缺失的元素是什么，我们无法回避计算机行业和人生的复杂性，我们所能做的只有控制这种复杂性，而DDD给了我们果断选择和放弃的信心：因为计算机领域的一切都是领域开发。
其次，DDD为创造复杂领域软件提供了切实可行的指导思想，赋予了探索更为复杂的领域软件这一未知世界的工具，这改变了我们观察世界的方式方法及行为模式。参加工作后，我曾经一度陷入到“怼”系统、“怼”项目的迷茫、疲惫和困惑中，也一度以“做架构、写框架、基础设施才是未来”为终极结论，但这都远非计算机领域的真相甚至相去甚远。DDD给了我们获知与原来生命不一样的见闻和觉知的能力，拓宽了我们的感知幅度，从而帮助我们重新建立对待计算机领域不一样的世界观。
六、DDD是联结计算机技术与计算机工程的桥梁
正统计算机专业一级学科“计算机科学与技术”下有三个二级学科，分别是计算机系统结构、计算机软件与理论和计算机应用技术。从概念上讲，我认为正如思维导图中红框所框出部分所处的位置，DDD是联结计算机技术与计算机工程的桥梁。
一方面，计算机技术层面的基础设施的产生源于实际计算机工程的需要。现实中千奇百怪的工程需求对基础设施不断产生着各种各样的要求，人们在对这些需求的抽象和总结中逐渐形成了各个细分场景和应对不同需求的基础设施。
另一方面，各种层次的模式和设计方法是顶尖的软件设计人员对工程实践的高度总结，DDD聚焦于解决复杂领域需求的实现，而正是复杂的领域需求将计算机工程的世界与计算机技术的世界联结在一起，让计算机技术为计算机工程服务并相互促进。
总之，计算机技术和计算机工程不是割裂的，他们相互交织，但又可以通过模式和DDD一类的设计方法在逻辑上进行划分，而DDD正是联结它们的桥梁。
七、DDD是所有计算机行业从业人员应该具备的意识
一个人愚蠢和无知都尚不可怕，最可怕的实际是没有意识。我们所有人都在思想政治课上学习过所谓马克思主义哲学中关于意识重要性的讨论，意识对于改造客观世界具有重要的指导意义，人们在意识的指导下能动地改造客观世界，正确的意识让人们可以根据客观实际在观念中构建客观上尚未出现的事物，并在这种观念的指导下进行实践活动，从而引起客观事物的某种变化，创造出新事物，促进人们改造世界活动的发展。
正如Evans所说，DDD让团队成员在项目中有意识地使用通用语言，并且不断对语言进行精化，由于团队成员不断地学习越来越多的领域知识，因此他们永远不会满足与现有模型的质量。他们把持续精化视作机会，把不适当的模型视作风险。他们知道，开发出高质量的、能够清晰反映出领域模型的软件并非易事，因此他们一丝不苟地运用设计技巧。他们也因为遇到障碍而跌倒过，但却始终坚持自己的原则，百折不挠，继续前进。
DDD向开发人员渗透的意识对于开发人员抽象客观世界的行为具有重要的指导意义，开发人员在DDD的指导下能够以比“在万不得已时进行单纯的代码级重构、系统间重构、夯掉重来的崩溃式演进”等具有更高能动性地从事开发活动，引导开发团队根据分析模式、设计模式、集成模式、新兴基础设施等客观实际在观念中构建客观上尚未出现的事物，并在这种观念的指导下进行实践活动，从而引起传统软件开发方法的某种变化，促进软件开发活动的发展。
我们每个人的经历和精力都是有限的，人与人之间的重要区别之一就在于关键节点时凭借意识所做出的关键选择，及不同意识形态所带来的“脑补”周围世界的能力。如果说面向对象的抽象能力、设计模式等是代码实现和编码技巧层面的意识，那么DDD则毫无疑问为实现领域需求而生的高层分析和建模层面的意识。因此，由于DDD为开发人员在面对无限宽广的领域开发时提供了脑补的可能和想象的空间，认为DDD是所有计算机行业从业人员应该具备的意识之一是没有问题的。
八、DDD引入了新的职业角色“领域建模专家”
除了诸如会计、货运、传统银行等小部分已经具有相对成熟领域模型的领域外，领域建模一般是一件较为艰难且需要高度技巧、灵活性和经验性的工作，尤其是刚刚开始尝试使用领域建模时。领域专家可能并不是一个职位或具体的人，因为领域专家可以是精通业务的任何人，这些人更了解领域的背景知识，他们可能是提出需求的某个业务人员，也可能是软件的设计者，也非常可能只是一个销售员；但是，领域建模专家在未来却很可能是一个职位或具体的人，即使计算机行业“智力过剩、劳力过剩”的悲剧真的出现，AI真的最终消灭了大部分开发人员，领域建模专家的重要性反而会更加凸显：
首先，优秀的软件设计人员自己应该可以自发性地认识到领域建模和设计的重要性，但领域建模本身是困难的，只有优秀的计算机从业人员才能处理领域建模中各种各样的模糊情况；
其次，当今的时代早已不再是关系数据库为通吃的时代，大量的领域需求需要多种新兴基础设施的辅助，领域建模需要自律和想象力，创建好的领域软件是需要学习和思考的活动。领域建模需要理解目标领域并将学到的知识融合到软件中，更加透彻地研究领域模型，并在可运行的软件中把模型表达出来。
因此，领域建模作为极具艺术性的工作，只有具有高度计算机专业素养、实践经验且具有自律、想象力和洞察力的“领域建模专家”才能胜任，“领域专家”在相当程度上同时兼具了传统“设计师”和“架构师”的概念。
九、DDD是“设计师”和“架构师”的必然要求
那么所谓的设计师和架构师究竟指的是什么、需要做什么、又需要做到什么呢？这是一个充满话题性的艰难话题。我们先来看一个极具讽刺性的事实：作为曾经痴迷考试的我，早在本科大二大三期间就已经考出过软件设计师、数据库系统工程师和系统分析师（我们暂且我的这种以考促学的行为，也不不讨论这套可悲的认证体系，和分析师这个可怜的名词），但充满讽刺和遗憾的是，我直到今天都其实并不知道我究竟是什么——以至于也许我本质上和野心上都远不仅于此，但介绍自己的时候我都干脆用J2EE工程师以蔽之。
在写这一条时我耗费了大量的时间，构思和尝试了数天，也在知乎上就这个问题看过几乎所有的回答（其中有些恰恰是错误的），但始终不得其法。可见，即使是知乎上敢于抖机灵、敢于面对全中国所有从业人员质疑的顶尖者对于这个问题也大概是模糊的，很难清晰地表述出来，这些回答大多是工程师们基于感知和体会的零散的总结，无外乎：①绝不是PPT架构师②本身就是优秀的程序员，否则不能服众③强大的编码能力、逻辑思维能力、抽象能力、想象能力、学习能力、领导力、好奇心④大量的项目经验⑤产出的不是代码而是一套可行性的方案，等等。
机缘巧合，就在我即将把这篇文章发出来前，我参加了SAP的一个讨论（详见第十三条），其中一个“盖大楼”的类比让我理解了“设计师”和“架构师”的职责，并彻底推翻了原本的内容。这个类比如下：
“盖大楼”的类比
其中，“资方”出钱盖楼让“设计师”帮他实现“梦想”，实现“梦想”与探究“真相”一样是人类社会进步的原动力之一，“设计师”对“资方”的“梦想”进行具象化，在与“架构师”进行可行性的权衡后给出“图纸”，随后的实施工作依次从上向下地由“架构师”传导给“工程师”，又由“工程师”传导给若干的“工头”和“工人”，“工人”则使用“原材料”盖楼，最后由“监理”保证施工结果与“图纸”的一致，这个过程与软件需求的开发极为相似。请注意，上图中“设计师”与“架构师”之间的横线按照Problem Finding和Problem Solving的层面进行了划分，尽管“设计师”所处的位置乍看与计算机领域似乎是反直觉的，但如果细想却确实如此，而且与本文之前的内容契合。从这个类比中可以得出几个结论：
首先，可悲的软考体系中“软件设计师”的叫法是一种幼稚的低级错误，作为一个中级职称，显然叫做“软件工程师“更为正确，同是中级职称的“数据库系统工程师”就叫做工程师。
其次，正如前文所述，包括我自身在内的很多人都是从事的ProblemSolving的工作，甚至深陷其中而难以跳出。
再次，传统工程实施是一个三角形，重实施不重设计；而创新类工作的则是一个倒三角形，重设计而不重实施。
当然，上图中的类比强调了“设计师”与具体实现的完全分开，强调“设计师”绝不参与具体的问题解决阶段；而在DDD中的“领域建模专家”恰恰在相当程度上同时包含了“设计师”、“架构师”甚至“工程师”的角色，而且不断强调设计和实现的不可分割。我想，这应该是一个需要权衡的问题，也正如之前所说的那样，理解DDD需要较深的专业底蕴和一线企业级编码及全流程经验；同样，要成为“设计师”和“架构师”，理解DDD又是必然的要求。这样，设计师和架构师究竟指的是什么、需要做什么、需要做到什么也就是不再是一个很难清晰地表述出来的概念了。
十、DDD是计算机从业人员的最终出路之一
当今计算机行业“智力匮乏、劳力匮乏”的时代已经结束，正处在“智力匮乏、劳力过剩”终末期向“智力过剩、劳力过剩”初级阶段的过渡过程中，一旦进入到这个阶段后匮乏的就只剩下了从事导图中“计算机科学”的小部分人。计算机行业在一定程度上是一个温水煮青蛙的行业，从业初期较其他行业高的起薪和诱惑众多的可选项容易给从业者造成错觉；然而，随着计算机行业日新月异新技术的不断涌现、技术领域垂直细分的不断细化、从业者自身年龄的不断增长、从业者精力不足支撑终身学习新知识等不利因素的出现，与医生、教师等积累性行业相比，从业者潜力和薪酬可能会在拐点到达后呈现出快速衰退或瓶颈的情况，今年以来诸如华为清退35岁以上员工、中兴员工跳楼等甚嚣尘上，知乎上更是疯狂出现了大量关于从业人员职业生涯走向的讨论。可以说，回答“计算机从业人员相对最优的最终职业出路应该是什么”这一问题实际是摆在所有从业者面前的迫切问题。
DDD在一定程度上可以成为这个问题的答案，领域建模专家也可以成为计算机从业人员的最终出路之一。正如Evans所说，由外行创建复杂软件的时代还远未到来。虽然掌握了一些初级技术的众多编程人员可以开发出特定种类的软件，但他们绝对没有能力开发出能在危机关头拯救公司的软件！
十一、DDD符合终身学习的价值理念及事物发展规律
世界上的一切事情都是运动发展的，这种运动发展是有规律的，这个规律即是运动发展的目标或方向只有前进和上升两种。如果一个事情的运动发展方向是向前发展，它前进方向的规律就只能是起起伏伏的波浪式；如果一个事情运动的方向是向上发展，它上升方向的规律就只能是一圈比一圈高的螺旋式。我们总是陷于波峰和波谷之间，常常因为想到了某个idea、想清楚了某个问题、觉得找到了某个问题的解决方案而兴奋不已，觉得自己无所不能，马上就要改变世界，make a big difference and a great fortune，瞬间站上潮头；然而，当一觉醒来，发现周围牛人和有资源的人们辈出，自己只是芸芸众生中的一只小蚂蚁，idea的实现又何其之难，人财物一样求而不得，又瞬间跌回谷底。从人类的认知规律和事物的发展规律上看，DDD是符合上述两个主要规律的：
首先，DDD符合终身学习的价值理念。DDD的核心观点之一就是理解目标领域并将学到的知识融合到软件中，领域驱动设计的实质就是消化吸收大量知识，最后产生一个反映深层次领域知识并聚焦于关键概念的模型。统一语言为团队成员更容易地理解彼此的工作的提供了可能，而统一语言形成的实质就是对知识的学习。
其次，DDD不反对诸如XP等敏捷方法，而是将领域驱动设计与敏捷开发过程进行相互增强，强调通过重构来加深理解。有价值的模型不是立即就出现的，他们需要对领域的深入理解。这种理解是一步一步得到的，首先需要深入研究模型，然后基于最初不成熟的模型实现一个初始设计，再反复改进这个设计。领域专家与开发人员的协作过程和开发过程都是迭代式的，而迭代式的开发过程在本质上符合螺旋式上升的运动发展基本规律。
再次，每次团队对领域有了新的理解后，都需要对模型进行改进，让模型反映出更丰富的知识，而且必须对代码进行重构以便反映出更深刻的模型，并使应用程序可以充分利用模型的潜力。这种方法有时会创造一种突破的机会，使我们得到更深刻的模型，同时快速进行一些更深入的设计修改。微小的重构每次可能只涉及一个对象，在这里加上一个关联或在那里转移一项职责，从领域软件的发展速度上看速度是慢的；而随着突破的产生，一旦突破出现就会给领域项目带来巨大的冲击，从领域软件的发展速度上看速度是快的，因而符合波浪式的运动发展基本规律。
总之，正如Evans所说，团队成员在项目中有意识地使用通用语言，并且不断对语言进行精化，由于他们不断地学习越来越多的领域知识，因此他们永远不会满足与现有模型的质量。他们把持续精化视作机会，把不适当的模型视作风险。他们知道，开发出高质量的、能够清晰反映出领域模型的软件并非易事，因此他们一丝不苟地运用设计技巧。他们也因为遇到障碍而跌倒过，但却始终坚持自己的原则，百折不挠，继续前进。
十二、DDD是中国高校计算机教育中的悲剧性缺失
很遗憾，除了网上斯坦福的开放课程外我没有出国受过教育，在国内也没有在目前世界排名第一的清华计算机系上过学，因此我不知道最顶级的计算机教育中是否对DDD有所强调。但是，仅就我自己目前所受到的专业教育而言，没有任何同学、老师或课程中强调过DDD在计算机领域的重要地位，在各大技术论坛上也鲜见关于DDD头条和讨论；在国内计算机专业考试认证体系的最高级别（如软考的系统分析师）中也压根没有提到过DDD。
如果能够排除因为“我自己太垃圾和我周围的人太垃圾而导致没有早了解DDD”这一因素的话（事实上我是通过同事和领导才开始尝试深入DDD的），那么按我自认为所接受的“正规专业科班教育”实际上除了软件类工程课程中千万遍重复的瀑布模型、敏捷开发、极限编程等等外，更多地偏向了公共专业基础而从未强调过DDD此类的分析和设计方法论。我想，如果在上学时有人向我强调过DDD的概念，我现在应该走得更远。尽管2012年时涛哥就讲解过将领域模型用于贷款系统但当时我的认知确实不足，甚至相当一段时间内一度认为业务系统无非也就是个“怼”。之所以造成DDD在中国高校计算机教育中悲剧性的缺失，我认为可能是由于以下的原因：
①一线教育实践者教育教学能力及计算机专业素养不过关。正如本文前文所述，理解DDD需要较深的专业底蕴和一线企业级编码及全流程经验，而目前设计国内高校计算机教育教学体系或从事一线的教育教学工作实践者，往往只具有计算机专业基础知识而不具备需要在长期实践中才能淫浸出的专业底蕴，由于其工作的特性更加难以具备真正一线的企业级编码和全流程实践经验，往往只聚焦某个细分领域，因而他们不能切身地体会DDD在计算机行业中的重要地位和作用。在教育教学理论和技巧方面，国内高校的一线教育实践者往往缺乏正规的教育学背景，在其教育教学过程中不能以适当的方法启发和诱导学生进行自主的探究式学习和发现式学习，只能局限在接收式学习，仅限于灌输式传授基础知识，导致学生难以构建出计算机领域的全景，更加无法意识到DDD在整个课程体系中的缺失。
②高校计算机教育教学体系的制定和设计欠合理。十年树木，百年树人，教育学作为一门研究教育现象、教育问题及其规律的社会科学，是在总结人类教育实践经验中逐步形成并经过长期积累而发展起来的。姑且不讨论近现代中国较之西方可悲的基础教育、职业教育和高等教育体系，仅就计算机这一短短几十年的行业而言，高等教育在诸多方面就已落后于国外。覆巢之下没有完卵，在从基础教育开始既可谓已全面崩溃的国内教育教学体系下，高校计算机教育也无法独善其身。教育是一种培养人的事业，而人的发展受到多种因素制约，导致教育的很多方面难以量化并直接影响评判标准；而当下对高校计算机教育教学体系的评价标准，只有我们自己。
③除教育教学体系的制定和设计外的问题外，高校计算机项目大多是研究性和实验性的，需求往往并非来自于实际的业务领域，而是某个专业方向下可行性原型的预研、探索或初步的原发性设计，与一线实施和工业级需求相去甚远，很少面临DDD所面对的复杂领域，因此学生和导师难以遇到DDD所重点解决的实际挫折，进而也不会有机缘考虑和寻找解决实际这类实际挫折的方法论，甚至压根不会意识到这类方法论的存在。
总之，根据我自己被教育的感受，由于高校计算机教育教学体系及一线教育实践者等方面的局限性，导致国内高校计算机教育在课程设计和教材选择方面存在不足。当今的软件工程的发展早已远远超越了瀑布开发和敏捷开发等概念和实践的阶段，除标准的软件工程、设计模式等的课程外，在高校计算机教育中引入DDD或类似的有关“分析模式”和“领域软件开发”的课程，尽早让相关专业的学生认识到“领域开发”在整个计算机领域中所处的地位是极为迫切和重要的，此类课程对于各类学科的学生也都是具有高层指导意义的。
十三、DDD没有明确指出而容易被人忽视的几个问题
在初步写完这篇文章之后，机缘巧合我参与了SAP一个有关创新（Innovation）的讨论，由SAP大中华区创新团队的负责人Rick主讲，其中关于DesignThinking的一些观点恰好弥补了DDD没有明确指出而容易被人忽视的几个问题。
我们在此首先纠正一般人对于“创新”的错误认识。正如Rick所说，Innovation这个词在中西方语境下的含义是不同的：在西方价值观中这个词是极为正面的，而在国内的价值观中则总是或多或少带有“不靠谱、不落地”等的贬义。我们总是不断地听到类似“基于大数据的XX创新项目”、“基于机器学习的XX创新项目”等一类带有KPI或政治导向性的项目名称，“大众创业、万众创新“更是被视作中国新常态下经济发展的”双引擎”之一，然而很多时候我们总是对这类项目名称报以相视一笑甚至嗤之以鼻的态度。事实上，如果学习过英文单词词根词缀学的相关知识，可以直接从词根上理解这个词在英文文化中所体现的价值观：一个元音加两个辅音双写的Inn仅用于发音辅助用途而没有实际含义，tion为名词后缀也没有实际含义，所以Innovation的词根为nova，而根据五个元音aeiou可在词根中为便于发音而进行任意互换的规律，nova实际应该对应navigation这个简单词的核心含义（探索、发现与方向等）。在个人英雄主义为主的西方价值观中，navigation与explore应该具有较多的褒义，以nova为词根的常见简单词还可以举出诸如novel（小说，凭空创造之意）等。
DDD没有明确指出而容易被人忽视的几个问题包括：
首先，尽管DDD确实是关于设计的，但DDD没有对“设计”的思维进行过多地强调，而更多地从“分析”的维度思考问题，仅在前言“设计过程与开发过程”一节中进行了极少的说明，没有明确划出“问题发现”和“问题解决”之间的界线。这可能与DDD所出现时代的历史局限性有关，或彼时的时代尚处在使用“分析”的眼光审视客观世界而没有到达使用“设计”的眼光来审视并进而改造客观世界的阶段有关。
其次，DDD强调在开发团队之间通过统一语言解决知识共享的问题，强调模型与实现之间的统一，强调划分了“领域专家”、“领域建模专家”的角色，但没有再对“模型实现专家”进行深入地划分。正如前文中所说，尽管DDD确实是关于设计的但更多地是从“分析”的维度思考问题，所以没有明确划出“问题发现”和“问题解决”之间的界线，更倾向于设计与过程的密不可分，这一点也已经在第九条中进行了讨论。
第三，DDD认为突破不是一个行为而是一个事件，强调突破是不能被制造的，认为强行设计突破只会使项目陷入困境。但是，如果站在更高的层面，按DesignThinking的观点看，突破像创新一样在一定程度上是可以通过方法论的指导产生的，DDD的本身有相当部分就是在为创新和突破创造可能。正如Evans所说，探索本身是永无止境的，但不是随机的。持续重构一般会让事物逐步变得有序，代码和模型的每一次精化都让开发人员有了更加清晰的认识，这使得理解上的突破成为可能。之后，一些列快速的改变得到了更符合用户需要并更加切合实际的模型，其功能性及表达能力急速增强，而复杂性却随之消失。与其说SAP的讨论是关于创新的，不如说是DesignThinking有利于创新的出现或DesignThinking的某些方法论为创新的出现提供了指导方法，而这与DDD中“突破”的概念非常类似，所谓的创新和突破都是正确的方法论所产生的正确结果之一，只不过通常只有在实现了许多适度的重构后才有可能出现突破。
确实，DDD不是万能的，更远非是完美的，它既不是完全抽象的玄学概念，也不是能够无脑落地的既成公式。当人们学习设计方法时，各种可能性另他们兴奋不已，然而真实项目的错综复杂又会为他们泼上一盆冷水。他们无法用所使用的技术来贯彻新的设计思想，或者不知道何时应该为了节省时间而放弃某个设计方面，何时又应该坚持不懈直至找到一个干净利落的解决方案。但是DDD所体现出的思想值得我们将其作为一种强大的工具，赖于高度灵活的我们将其与更高层的思维方式和方法论相结合，用于和指导现实的生产活动。
我想，如果在上学时有人向我强调过DDD的概念，我现在应该走得更远；如果在我参加工作之初有人向我强调过DDD的概念，那么我现在过得应该更加优雅。因此：
①如果你目前仍然在学校中，请读一读DDD吧。DDD能够给你一个更高的全局专业视角让你在职业生涯中做出更加正确的选择，尽管也许你还暂时不能理解什么是企业级/工业级产品，也暂时不能理解“架构”是如何服务于企业级/工业级产品，也暂时不能理解“模式”是如何服务于架构和编码工作的。
②如果你已经工作，但每天陷于低端且重复性的业务逻辑编码工作，对处于崩溃边缘的项目充满质疑但两眼一片茫然不知何去何从，请读一读DDD吧。DDD能够让你明白除了每天写代码和调试外还有更好的方法，在学习DDD过程中可以学习到更多设计的思想和建立对设计的感觉。
③如果你已经工作，自以为见识过了所谓了工业级代码、遇到并解决过了各种各样的生产问题、读过了些实际工程性的书籍、以成为设计师/架构师为目标，但却限于囚徒困境和职业天花板、午夜梦回看到中兴员工跳楼不知何去何从时，请读一读DDD吧。
④如果你已经工作，但作为产品经理、需求分析人员而每天陷于为项目的变更、失控的项目质量而疲于奔命、无法面对频繁加班下属的眼光、同样在午夜梦回怀疑人生时，请读一读DDD吧。
⑤如果你已经工作，但作为Team Leader、广义项目经理、高级开发人员或专家而每天陷于为项目的变更、失控的项目质量疲于奔命、无法面对频繁加班下属的眼光、不能指导团队保持正确的方向、同样在午夜梦回怀疑人生时，请读一读DDD吧。
⑥如果你身边有刚刚进入计算机行业的在校生、实习生、尚有学习欲望的同事等，请向他们推荐DDD吧，这样才能让我们共同所处的行业不断进步。
⑦如果你身在计算机行业，但没有看过DDD，请读一读DDD吧！
最后，让我们尝试回答开头我一直纠结的三个问题：
①计算机专业学习的相对最优路径应该是什么？
答：快速完成专业基础课程的学习，用尽可能短的时间建立真正的全景认知（任何问题有了全景后，最终应该都是选择的问题），勇敢地选择导图中自己最喜欢的一点进行一定程度的深耕，在成为相应方向有一定影响力人的同时，永远将DDD为领域创造价值的核心价值观放在首位，始终以互联网为传播工具和首先为他人创造价值为前提，心有多大舞台就有多大。
②计算机从业人员相对最优的最终职业出路应该是什么？
答：我们所处的世界是一个在动态中平衡的世界，教育和咨询是建立在人类学理论上的永恒主题，而同时从事教育、咨询和一线开发实践的领域建模专家则是一个现实的可选项。
③所谓的设计师和架构师究竟指的是什么、需要做什么、需要做到什么？
答：参见第九条的讨论。
正如Evans所说，业务软件大可不必是拼凑而成的杂乱系统，与复杂的领域搏斗，把它转化为可理解的软件设计，对于优秀的技术人员来说同样是意向激动人心的挑战。利用DDD，我们可以编写出优秀的软件，当大部分项目由于规模和复杂度的积累而举步维艰，开始僵化而成为遗留系统时，我们的项目却能加速前进，它在扩展的时候不会对我们构成限制，反而会为我们创造新的机会（因为竞争对手可能是僵化的），并且不断为其使用者提供价值！
欲望是众多的，选择是艰难的，放弃是艰难的。我们需要去选择成为导图中的某一类人或是比导图更大范围中的某一类人，并同样需要为成为这一类人放弃某些东西。DDD作为计算机领域不可或缺的一部分，在相当程度上可以让我们看清计算机领域的全景，让我们在计算机领域机内和计算机领域外都做出更加明智的选择，给予我们更多果断放弃的勇气和突破的可能。我一直坚信，码农的双手具有无穷无尽的创造力，计算机行业在可预见的未来中是所有行业所不能绕过的关键节点，如果你还记得北邮人论坛上一位师兄的年终总结，那么你应该知道我在说什么。希望DDD和DDD中透漏出只言片语的哲学带给我们的启发，能够让我们及时审视和明确自己在领域内和人生中的定位，能够为我们创造站在计算机领域外的人生中、去Design更大Bussiness和Future的意识、勇气、方法、自信和可能！
参考资料：
1、Apache ISIS Documentation
2、Eric Evans，《领域驱动设计：软件核心复杂性应对之道》
3、Vaughn Vernon，《实现领域驱动设计》
4、Eric Freeman、Elisabeth Freeman，《Head First设计模式》
5、Gregor Hohpe、Bobby Woolf，《企业集成模式：设计、构建及部署消息传递解决方案》
6、Martin Fowler，《企业应用架构模式》
DDD In Action
后记：
从2013年参加工作以来，我一直以“解决现实问题，让绝大部分干系人满意”为做事的核心原则之一，曾经为很多不同类型的人解决过不同类型的很多问题，也曾经一度陷入到“怼”系统、“怼”项目的迷茫、疲惫和困惑中，也一度以“做架构、写框架、基础设施才是未来”为终极结论。我在看到了很多不如我的同业的同时，也看到了很多在更为广阔的专业领域范围内外中比我取得概念上更大成功的人，并为之在诸多方面感到困惑。当我在很快即将迈入30岁的大门，回顾2017年时，我想对我个人而言最大的收获就是相对深入地了解了DDD，DDD带给我的感觉丝毫不亚于嵌入式和逆向所带我的感觉，这个小小的概念甚至开始打开了我解答有关哲学、个人修为等很多看似玄学的困惑和更多其他问题的可能。涛哥在2012年时一个人苦口婆心讲解DDD的情景似乎仍然历历在目，但遗憾的是当时我却没有足够能力和认知去体会。今天，我也把我对DDD的一点粗浅认知苦口迫性地总结成了这篇文章，包含了我阶段性的一点思考。如果你觉得我说得不对那么请忽略即可，如果你觉得对你有用那么我很欣慰MayTheForceBeWithYou，如果你认同那么让我们共同携手一带一路，如果你觉得我能为你所用那么请拉我一把吧。
大道至简，殊途同归，我们每个人都是社会本位论下的人，在探索客观世界真相上所选择的路径是不同的，但所追求的成功却在概念上大致相同。相信就像Evans所说的那样，我们自己，一定会像我们所设计的系统一样，会随着持续重构逐步让概念上的突破成为可能，得到更符合客观世界、功能性及表达能力急速增强，而复杂性随之消失的模型！请各位业界精英批评指正。
转载时请保留出处，违法转载追究到底：进城务工人员小梅 » DDD领域驱动设计浅见：计算机领域不可或缺的一部分