问题空间和解空间哲学家常常会围绕真实世界和理念世界的映射关系探索人类生存的意义，即所谓“两个世界”的哲学思考。软件世界也可一分为二，分为构成描述需求问题的真实世界与获取解决方案的理念世界。整个软件构建的过程，就是从真实世界映射到理念世界的过程。如果真实世界是复杂的，在映射为理念世界的过程中，就会不断受到复杂度的干扰。根据Allen Newell和Herbert Simon的问题空间理论：“人类是通过在问题空间（problem space）中寻找解决方案来解决问题的”，构建软件（世界）也就是从真实世界中的问题空间寻找解决方案，将其映射为理念世界的解空间（solution space）来满足问题空间的需求。因此，软件系统的构建实则是对问题空间的求解，以获得构成解空间的设计方案，如图所示。为什么要在软件构建过程中引入问题空间和解空间？实际上，随着IT技术的发展，软件系统正是在这两个方向不断发展和变化的。在问题空间，我们要解决的问题越来越棘手，空间规模越来越大，因为随着软件技术的发展，许多原本由人来处理的线下流程慢慢被自动化操作所替代，人机交互的方式发生了翻天覆地的变化，IT化的范围变得更加宽广，涉及的领域也越来越多。问题空间的难度与规模直接决定了软件系统的复杂度。针对软件系统提出的问题，解决方案的推陈出新自然毋庸讳言，无论是技术、工具，还是设计思想与模式，都有了很大变化。解决方案不是从石头里蹦出来的，而必然是为了解决问题而生的。面对错综复杂的问题，解决方案自然也需要灵活变化。软件开发技术的发展是伴随着复用性和扩展性发展的。倘若问题存在相似性，解决方案就有复用的可能。通过抽象寻找到不同问题的共性时，相同的解决方案也可以运用到不同的问题中。同时，解决方案还需要响应问题的变化，能在变化发生时以最小的修改成本满足需求，同时保障解决方案的新鲜度。无疑，构成解空间的解决方案不仅要解决问题，还要控制软件系统的复杂度。问题空间需要解空间来应对，解空间自然也不可脱离问题空间而单独存在。对于客户提出的需求，要分清楚什么是问题，什么是解决方案，真正的需求才可能浮现出来。在看清了问题的真相之后，我们才能有据可依地寻找真正能解决问题的解决方案。软件构建过程中的需求分析，实际就是对问题空间的定位与探索。如果在问题空间还是一团迷雾的时候就贸然开始设计，带来的灾难性结果是可想而知的。徐锋认为，“要做好软件需求工作，业务驱动需求思想是核心。传统的需求分析是站在技术视角展开的，关注的是‘方案级需求’；而业务驱动的需求思想则是站在用户视角展6开的，关注的是‘问题级需求’。”怎么区分方案级需求和问题级需求？方案级需求就好比一个病人到医院看病，不管病情就直接让医生开阿司匹林，而问题级需求则是向医生描述自己身体的症状。病情是医生要解决的问题，处方是医生提供的解决方案。那种站在技术视角展开的需求分析，实际就是没有明确问题空间与解空间的界限。在针对问题空间求解时，必须映射于问题空间定义的问题，如此才能遵循恰如其分的设计原则，在问题空间的上下文约束下寻找合理的解决方案。领域驱动设计为问题空间与解空间提供了不同的设计元模型。对于问题空间，强调运用统一语言来描述需求问题，利用核心子领域、通用子领域与支撑子领域来分解问题空间，如此就可以“揭示什么是重要的以及在何处付出努力”。除去统一语言与子领域，其余设计元模型都将运用于解空间，指导解决方案围绕着“领域”这一核心开展业务系统的战略设计与战术设计。战略设计和战术设计对于一个复杂度高的业务系统，过于辽阔的问题空间使得我们无法在深入细节的同时把握系统的全景。既然软件构建的过程就是对问题空间求解的过程，那么面对太多太大的问题，就无法奢求一步求解，需要根据问题的层次进行分解。不同层次的求解目标并不相同：为了把握系统的全景，就需要从宏观层次分析和探索问题空间，获得对等于软件架构的战略设计原则；为了深入业务的细节，则需要从微观层次开展建模活动，并在战略设计原则的指导下做出战术设计决策。这就是领域驱动设计的两个阶段：战略设计阶段和战术设计阶段。战略设计阶段要从以下两个方面来考量。问题空间：对问题空间进行合理分解，识别出核心子领域、通用子领域和支撑子领域，并确定各个子领域的目标、边界和建模策略。解空间：对问题空间进行解决方案的架构映射，通过划分限界上下文，为统一语言提供知识语境，并在其边界内维护领域模型的统一。每个限界上下文的内部有着自己的架构，限界上下文之间的协作关系则通过上下文映射来体现和表达。

你可以，不代表你应该。（Just because you can, doesn’t mean you should.）——施莉琳•凯尼恩7.4　DDD的优势通过上面的介绍，相信读者对DDD有了一些认识，接下来对DDD的优势会更容易接受。如果一开始不能接受DDD也没有关系，我其实也经历过“排斥—接受—使用”的过程。当真正领会DDD的精髓之后，我就再不愿意回到以前的开发模式了。下面将DDD带来的核心好处总结如下。 7.4.1　统一语言统一语言（Ubiquitous Language）的主要思想是让应用能和业务相匹配，这是通过在业务与代码中的技术之间采用共同的语言达成的。业务语言起源于公司的业务侧，业务侧拥有需要实现的概念。业务语言中的术语由公司的的业务侧和技术侧通过协商来定义（意味着业务侧也不能总是选到最好的命名），目标是创造可以被业务、技术和代码自身无歧义使用的共同术语，即统一语言。代码、类、方法、属性和模块的命名必须和统一语言相匹配，必要的时候需要对代码进行重构！试想，在PRD文档、设计文档、代码以及团队日常交流中，如果有一套领域术语是统一无歧义的，是否会极大地提升沟通和工作效率？在日常工作中，因为概念理解不一致，或者语言表达上的问题，导致沟通效率低，甚至发生误解的情况实在太多了。所以，明确概念、形成统一语言至关重要。7.4.2　面向对象DDD的核心是领域模型，这一方法论可以通俗地理解为先找到业务中的领域模型，以领域模型为中心，驱动项目开发。领域模型的设计精髓在于面向对象分析、对事物的抽象能力，一个领域驱动架构师必然是一个面向对象分析的大师。DDD鼓励我们接触到需求后第一步就是考虑领域模型，而不是将其切割成数据和行为，然后用数据库实现数据，用服务实现行为，最后造成需求的首尾分离。DDD会让你首先考虑业务语言，而不是数据。DDD强调业务抽象和面向对象编程，而不是过程式业务逻辑实现。重点不同，导致编程世界观不同。7.4.3　业务语义显性化统一语言也好，面向对象也好，最终的目都是为代码的可读性和可维护性服务。统一语言使得我们的核心领域概念可以无损地在代码中呈现，从而提升代码的可理解性。例如，在银行转账的案例中，按照事务脚本的写法来写“透支策略”的业务概念，其含义完全被淹没在代码逻辑中没有突显出来。但是，如果我们使用策略模式将其抽象出来，让业务语义得到显性化的表达，代码的可读性就会提升很多。面向对象也是让代码尽量体现领域实体和实体之间的关系原貌，所以目的也是业务语义被显性化地表达，显性化的结果是代码更容易被理解和维护，殊途同归，一切都是为了控制复杂度。在软件的世界里，任何的方法论如果最终不能落在“减少代码复杂度”这个焦点上，那么都是有待商榷的。7.4.4　分离业务逻辑和技术细节代码复杂度是由业务复杂度和技术复杂度共同组成的。实践DDD还有一个好处，是让我们有机会分离核心业务逻辑和技术细节，让两个维度的复杂度有机会被解开和分治。如图7-8所示，核心业务逻辑是整个应用的核心，最好只是简单Java类（Plan Old Java Object，POJO）。也就是说，核心业务逻辑对技术细节没有任何依赖，依赖都是由外向内的，即使有由内向外的依赖，也应该通过依赖倒置来反转依赖的方向。通过这样的划分，Entities只要安安心心地处理业务逻辑就好，业务逻辑越复杂，这样划分带来的好处越明显。为什么说数据库、框架和UI都是技术细节呢？数据库：业务逻辑不应该受限于存储方式，也就是不论你是使用关系型数据库还是NoSQL，都不应该影响业务逻辑的实现。数据本身很重要，但数据库技术仅仅是一个实现细节。UI：UI只是一种I/O设备的呈现，Web、WAP和Wireless都是不同的I/O，我们的核心业务逻辑应该与如何呈现解耦，以及针对不同的端可以使用不同的适配器（Adaptor）去做适配。框架：不要让框架侵入我们的核心业务代码，以Spring为例，最好不要在业务对象中到处写@autowired注解。业务对象不应该依赖框架。这么说来，这些技术细节是不重要了吗？不是的，技术细节是一个系统的必要组成部分，也非常重要。技术细节和核心业务逻辑是两个维度的重要性，如果把软件比喻成一个人，那么核心业务逻辑是大脑，技术细节是身体，二者都很重要，分开处理主要是为了降低复杂度。7.5　DDD的核心概念7.5.1　领域实体毫不夸张地说，我们的软件系统就是对现实世界的真实模拟。如图7-9所示，现实世界中的事物在软件世界中可以被模拟成一个对象：该事物在现实世界中被赋予什么职责，在软件世界中就被赋予什么职责；在现实世界中拥有什么特性，在软件世界中就拥有什么属性；在现实世界中拥有什么行为，在软件世界中就拥有什么函数；在现实世界中与哪些事物存在怎样的关系，在软件世界中就应当与它们发生怎样的关联。这正是面向对象编程的核心思想，也是DDD中寻找领域实体的核心思想。假如现在你需要设计一个中介系统，一个典型的User Story是“小明去找工作，中介让他留个电话，有工作机会就会通知他”。我们要如何寻找该业务中的关键领域实体呢？一个简单的方式就是“找名词”，分析这些名词，不难得到以下可能成为实体的候选项。小明：一个求职者。电话：求职者的相关信息，可以是一个属性。中介：可以拆解为中介公司和中介公司的员工两个概念。工作机会：对于中介系统来说，工作机会应该是最关键的实体之一。通知：作为名词是一个实体，但是作为一个动词是在暗示我们可以使用Notify。是的，对于这个简单的User Story，这样分析就可以了。当然，随着更多的Story被加入，我们会补充更多的实体，比如增加了“中介费是按照小明第一个月工资的30%收取”，那么就可能要引入“订单”和“支付”等实体。以上就是我在实际工作中寻找领域实体的大致过程。从方法论的角度来说，也叫作“用例分析法”，详细的步骤会在7.6.1节中介绍。

为什么想写这个，主要是感受到同志们的学习高潮,恨不得各种练习，但又遭遇到一些挑战，比如“我想在项目中推行DDD，但担心其他人不配合”，“DDD门槛太高，概念多”......就笔者之所见，一个标榜实践TDD的项目要不是口号，噱头，要不就失败了，如同要推行DDD的一样。项目不是兵器的练兵场，首先要回到“问题域”，要解决什么问题。一个以推行DDD为目标的项目，总觉得有点慌。就笔者之所见所闻，有1个典型的推广XXX的case。一个是某司的一位空降boss，是一位有创派别的国内“敏捷”专家。当然，敏捷专家几乎都耻于谈敏捷 ，这样也就和其他人谈的“敏捷”无法区分开去。空降boss一来大谈敏捷实践和各种老外前辈云云，但却被团队吐槽，因为那会这群码农最关心的是“生存问题”，去总部找活回来干的问题 。几个月后这位boss转变了思路，通过抓稳定迭代的release，促进快速反馈，赢得了团队尊重和客户认可。这个case，让人懂得了 一个道理，一位病人发烧了，医生可以先采取措施让他退烧，然后治疗。病人并不喜欢医生跟他讲中西医区别，药理知识。第二个道理就是，鸡蛋好吃，你非要去分辨是那只鸡下的蛋，并无多大必要。团队员工的期待是空降老板给我们指方向，找活干，加薪而不是推广敏捷 。同理，江湖上流传着这样的说法：老板看问题的视角是，“这个需求很简单，怎么实现我不管”。某些技术人员的视角可能是，“十八般武艺都用，至少面试用得着”。另外很诡异的一个点在于，人类对于所谓 “建议”往往听不进去，然后总会找到一堆来证伪，然后又乐此不彼的“学习着”，争论他认为对的观点...笔者自己也做过推广XXX的事情，持续集成。这东西大家都知道，我们之前有一个简单的规约，就是每天下班前的构建要绿色 ，单元测试和接口测试都得通过。好些同学怨声一片，代码都写不完，干嘛还要去写测试代码？尤其是之前测试代码覆盖率巨低的系统，几百个测试case不通过的系统 ......采取简单粗暴的每天强制的方式，存量用例设定计划治理，研发同学不情愿的被要求每天跑CI......在大显示屏的曝光和强迫之下，持续了半年多... 后来有项目团队主动分享CI带来的好处，测试代码在他们后面的重构过程中发挥了作用，心里有底多了。这个故事让我“自以为是”的懂得了第二个道理，让人懂得或者转变是很难的，猴子自己上树和硬推猴子屁股上树的区别。如果你拿着香蕉在猴子面前晃，就不一样了。 Greg Young 先生有一个presentation ，主题就是“7 Reasons Why DDD Projects Fail“，简单总结DDD 失败的要点：Lack of intent（缺乏意图）Anemic Domain Model（贫血模型）DDD-LiteLack of isolation （缺乏隔离）Ubiquitous what?Lack of refinement（缺乏完善）Proxy Domain Expert (Business analyst)   笔者稍微谈一下自己的理解。1、首要解决通用语言UL(Ubiquitous Language问题，统一域语言。张逸老师指出，统一语言是提炼领域知识的产出物，获得统一语言就是需求分析的过程，也是团队中各个角色就系统目标、范围与具体功能达成一致的过程。使用统一语言可以帮助我们将参与讨论的客户、领域专家与开发团队拉到同一个维度空间进行讨论，若没有达成这种一致性，那就是鸡同鸭讲，毫无沟通效率，相反还可能造成误解。因此，在沟通需求时，团队中的每个人都应使用统一语言进行交流。可以想象一下，做支付、银行、电商行业的朋友在谈及记账、清算、结算、核算这些词的时候是否是一个明确统一的含义。一旦确定了统一语言，无论是与领域专家的讨论，还是最终的实现代码，都可以通过使用相同的术语，清晰准确地定义领域知识。重要的是，当我们建立了符合整个团队皆认同的一套统一语言后，就可以在此基础上寻找正确的领域概念，为建立领域模型提供重要参考。前几天和某社区电商的一位工程师聊天，他们把给商家返佣之类的纳入到“清算”的范畴。这里他们用的“清算”肯定跟银行间“清算”不是一回事情。2、没有基于通用语言建立的所谓的聚合，实体，值对象，只能算是DDDLite，只是技术层面的一种设计方式。3、要解决好隔离问题，则需要以一种最宏观的角度去对“问题域”进行拆分，来划分“界限上下文”，最终形成一个具有俯瞰视角的“上下文映射图”。这里特别说一下“界限上下文”和问题域、以及服务谁，产生什么价值息息相关。比如一个采用第三方支付（支付宝）的小店网站，可能并不对支付宝背后的网联，以及银行渠道进行建模。4、refinement的问题架构腐化见怪不怪，如何领域层腐化了就“烂到跟上”。笔者见过一个系统，初期磨拳搽掌，建造者经验丰富，算是很成功的开端。但是若干年后这个系统domain层的代码和当初的领域模型图大相径庭，面目全非。持续的refinement、保鲜非常重要。另外，前几天和一位TL聊天，他说，我很注重代码追求的，为什么1年多我没怎么看代码，他们完全不是按照我想象的样子在写代码。

包结构分层是属于大粒度的职责划分，太粗，我们有必要往下再down一层，细化到包结构的粒度，才能更好的指导我们的工作。还是拿一堆玩具举例子，分层类似于拿来了一个架子，分包类似于在每一层架子上又放置了多个收纳盒。所谓的内聚，就是把功能类似的玩具放在一个盒子里，这样可以让应用结构清晰，极大的降低系统的认知成本和维护成本。那么，对于一个后端应用来说，应该需要哪些收纳盒呢？这一块的设计真可谓是费了老鼻子劲了，基本上每一次COLA的迭代都会涉及到包结构的调整，迭代到现在，才算基本稳定下来。各个包结构的简要功能描述，如下表所示：层次包名功能必选Adapter层web处理页面请求的Controller否Adapter层wireless处理无线端的适配否Adapter层wap处理wap端的适配否App层executor处理request，包括command和query是App层consumer处理外部message否App层scheduler处理定时任务否Domain层model领域模型否Domain层ability领域能力，包括DomainService否Domain层gateway领域网关，解耦利器是Infra层gatewayimpl网关实现是Infra层mapperibatis数据库映射否Infra层config配置信息否Client SDKapi服务对外透出的API是Client SDKdto服务对外的DTO是你可能会有疑问，为什么Domain的model是可选的？因为COLA是应用架构，不是DDD架构。在工作中，很多同学问我领域模型要怎么设计，我的回答通常是：无有必要勿增实体。领域模型对设计能力要求很高，没把握用好，一个错误的抽象还不如不抽象，宁可不要用，也不要滥用，不要为了DDD而DDD。问题的关键是要看，新增的模型没有给你带来收益。比如有没有帮助系统解耦，有没有提升业务语义表达能力的提升，有没有提升系统的可维护性和可测性等等。模型虽然可选，但DDD的思想是一定要去学习和贯彻的，特别是统一语言、边界上下文、防腐层的思想，值得深入学习，仔细体会。实际上，COLA里面的很多设计思想都来自于DDD。其中就包括领域包的设计。前面的包定义，都是功能维度的定义。为了兼顾领域维度的内聚性，我们有必要对包结构进行一下微调，即顶层包结构应该是按照领域划分，让领域内聚。也就是说，我们要综合考虑功能和领域两个维度包结构定义。按照领域和功能两个维度分包策略，最后呈现出来的，是如下图所示的顶层包节点是领域名称，领域之下，再按功能划分包结构。例如，在我们刚刚上线的一个云店铺（cloudstore）项目中，按照COLA的分包策略，我们在每一个module下面首先按照领域做一个顶层划分，然后在领域内，再按照功能进行分包。解耦“高内聚，低耦合”这句话，你工作的越久，就越会觉得其有道理。所谓耦合就是联系的紧密程度，只要有依赖就会有耦合，不管是进程内的依赖，还是跨进程的RPC依赖，都会产生耦合。依赖不可消除，同样，耦合也不可避免。我们所能做的不是消除耦合，而是把耦合降低到可以接受的程度。在软件设计中，有大量的设计模式，设计原则都是为了解耦这一目的。在DDD中有一个很棒的解耦设计思想——防腐层（Anti-Corruption），简单说，就是应用不要直接依赖外域的信息，要把外域的信息转换成自己领域上下文（Context）的实体再去使用，从而实现本域和外部依赖的解耦。在COLA中，我们把AC这个概念进行了泛化，将数据库、搜索引擎等数据存储都列为外部依赖的范畴。利用依赖倒置，统一使用gateway来实现业务领域和外部依赖的解耦。其实现方式如下图所示，主要是在Domain层定义Gateway接口，然后在Infrastructure提供Gateway接口的实现。举个例子，假如有一个电商系统，对于下单这个操作，它需要联动订单服务、商品服务、库存服务、营销服务等多个系统才能完成。那么在订单域，该如何获取商品和库存信息呢？最直接的方式，无外乎就是RPC调用商品和库存服务，拿到DTO直接使用就完了。然而，商品域吐出的是一个大而全的DTO（可能包含几十个字段），而在下单这个阶段，订单所需要的可能只是其中几个字段而已。更合适的做法，应该是在订单域中，使用gateway对商品域和库存域的依赖进行解耦。这样做有两个好处，一个是降低了对外域信息依赖的耦合；另一个是通过上下文映射（Context mapping），确保本领域边界上下文（Bounded context）下领域知识的完整性，实现了统一语言（Ubiquitous language）。COLA Archetype以上就是COLA架构的核心内容了。然而这么多module，这么多package，如果要手动去创建的话，是非常繁琐和费时的。为了能够快速创建满足COLA架构的应用，我创建了两个Maven Archetype。1.        一个是用来创建纯后端服务的archetype：cola-archetype-service。2.        一个是用来创建adapter和后端服务一体的web应用archetype：cola-archetype-web。另外，你也可以使用阿里云的应用生成器去生成一个COLA应用，只是那边的版本没有同步更新，可能会老旧一点。COLA组件使用过老版本COLA的同学，应该知道，COLA除了架构之外，还提供了一些框架级别的功能，比如拦截器功能，扩展点功能等。之前，这种框架功能和架构混淆在一起，会让人以为使用COLA，就必须要使用这些功能。实际上二者是可以分开使用的，也就是说，你可以单纯的使用COLA架构，而不使用任何COLA组件提供的功能也是完全没问题的。当然，我还是强烈推荐你可以有选择的使用这些COLA组件，毕竟这些组件都是我们在实际工作中的总结沉淀，其复用性和价值是被反复验证过的。为了方便管理，以及更清晰的把架构和框架区分开来。在此次COLA 4.0的升级中，我把这些功能组件全部收拢到了cola-components下面。到目前为止，我们已经沉淀了以下组件：组件名称功能版本依赖cola-component-dto定义了DTO格式，包括分页1.0.0无cola-component-exception定义了异常格式，主要有BizException和SysException1.0.0无cola-component-statemachine状态机组件1.0.0无cola-component-domain-starterSpring托管的领域实体组件1.0.0无cola-component-catchlog-starter异常处理和日志组件1.0.0exception,dto组件cola-component-extension-starter扩展点组件1.0.0无cola-component-test-container测试容器组件1.0.0无这些组件是一个良好的开端，我相信，在未来会有更多有用的组件加入。当然，作为一个开源项目，如果你有好的组件idea，欢迎你随时为这个组件库添砖加瓦。COLA 4.0总结一下，在本次COLA升级中，我们进一步明确了架构和框架功能的定义。升级之后，如下图所示，COLA会被分成COLA架构和COLA组件两个部分：1.        COLA架构：关注应用架构的定义和构建，提升应用质量。2.        COLA组件：提供应用开发所需要的可复用组件，提升研发效率。image.pngCOLA 开源地址： https://github.com/alibaba/COLA你可以按照以下步骤去使用COLA：** 第一步：安装 cola archetype ** 下载cola-archetypes下的源码到本地，然后本地运行mvn install安装。** 第二步：安装 cola components ** 下载cola-components下的源码到本地，然后本地运行mvn install安装。** 第三步：创建应用 ** 执行以下命令：mvn archetype:generate  -DgroupId=com.alibaba.demo -DartifactId=demoWeb -Dversion=1.0.0-SNAPSHOT -Dpackage=com.alibaba.demo -DarchetypeArtifactId=cola-framework-archetype-web -DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=4.0.0命令执行成功的话，会看到如下的应用代码结构：** 第四步：运行应用 ** 首先在demoWeb目录下运行mvn install（如果不想运行测试，可以加上-DskipTests参数）。然后进入start目录，执行mvn spring-boot:run。运行成功的话，可以看到SpringBoot启动成功的界面。生成的应用中，已经实现了一个简单的Rest请求，可以在浏览器中输入 http://localhost:8080/helloworld 进行测试。

我们今天来看下事件驱动架构，这个架构主要包括两种拓扑，调度者(Mediator)和代理(Broker)。我们今天主要看一下调度者拓扑。  事件驱动架构模式是一个非常流行的分布式异步架构模式，用来构建高度可扩展性高的应用程序。它也具有高度的适应性，并且可以用来构建小型应用和复杂的大型应用。事件驱动架构是由高度解耦，单一目的的事件处理组件组成，可以异步接收和处理事件。   事件驱动架构模式主要有两个主要的拓扑组成，调度者和代理者。调度者拓扑通常当你需要中心化的调度者通过一个事件协调完成多个步骤的操作时使用，而代理者拓扑则当你想要完成事件链，但是不想要中心化的调度者时使用。由于这两种拓扑的架构特性和实现策略不同，所以对这两种拓扑的深入了解能够使你在具体的场景中能够更好的做出选择。 调度者拓扑   当事件由多个步骤组成，且需要协调执行事件时，就是调度者拓扑的使用场景。例如：股票交易：一个股票交易事件可能需要：验证交易验证股票交易的各种规则将交易分配给代理人，并计算佣金最后再将交易放给代理人这些步骤需要一定程度的协调以确定哪些步骤是顺序或并行执行。   调度者拓扑有四个主要的架构组件：事件队列，事件调度者，事件通道，事件处理器。整个事件流以客户端发送一个事件到事件队列为起点，将事件传输到事件调度者。事件调度者接收到初始化事件后，通过发送额外的异步事件到事件通道来执行每一步的处理。事件处理器监听事件通道，接收来自事件调度者的事件，并执行事件的具体业务逻辑。下图展示了事件驱动架构中一般的调度者拓扑：    架构可能有上百个事件队列。事件驱动架构模式并指定执行事件队列组件的具体实现；事件对应可能是一个消息队列，WebService,或者两者的混合体。   调度者拓扑有两种类型的事件：初始化事件和处理事件。初始化事件是调度者接收到的事件，处理事件是由调度者生成的，并由事件处理组件接收。   事件调度者组件负责协调初始化事件涉及的所有子步骤。在初始化事件阶段，事件调度者发送具体的处理事件到事件通道，事件处理器接收到事件并处理它。注意：事件调度者并不执行业务逻辑去处理初始化事件，而是将初始化事件分解为多个子步骤/事件。  事件通道是用于事件调度者异步传递多个具体的处理事件到事件处理器。事件通道既可以是消息队列，也可以是消息主题，尽管消息主题被广泛用于调度者拓扑以满足处理事件能够被多个事件处理器处理（基于接收到的事件来执行不同的任务）。   事件处理器组件包含处理事件所需要的应用业务逻辑。事件处理器是自我界定的，独立的，高度解耦的架构组件，在应用程序或系统中执行具体的任务（业务逻辑）。每个事件处理器可以有不同的业务粒度,细粒度（例如：计算订单的销售税），粗粒度（处理保险索赔）。重要：一个事件处理器应该处理单一的业务逻辑，并且不要依赖其他事件处理的来完成它的业务。   事件调度者的实现可以有多种方式。作为架构师，你应该深入理解每个实现方式，以确保你选择的事件调度者能够满足你的业务需求。   最简单和通用的事件调度者是使用开源组件，例如：Spring Integeration,Apache Camel 或者Mule ESB。在这些开源组件中，通过Java代码或者DSL实现了事件流。对于更复杂的调度和编排，你可以使用BPEL（业务流程执行语言）和BPEL引擎（如：开源Apche ODE）来完成。BPEL是类似于标准XML语言，来描述数据和初始化事件的处理步骤。对于大型应用如果需要更复杂的编排（包括人机交互的步骤），你可以使用业务流程管理来实现调度者，例如jBPM。 使用调度者拓扑的关键是理解你的需求并使用正确的调度者实现。使用开源组件来实现非常复杂的业务流程管理编排是一种错误的做法，就像使用BPM解决方案来执行简单的路由逻辑一样。 为了说明调度者拓扑是如何工作的，假设你通过保险公司投保，然后你需要搬家。在这种情况下，初始化事件可以称为搬家事件。调度者处理一个搬家事件的步骤可能包括下图内容：在初始化事件步骤，事件调度者创建一个处理事件（例如：改变地址，重新计算价格等），发送处理事件到事件通道，并等待事件处理器将事件处理完成（例如：用户处理器，价格处理器等）。这些流程会一直持续直到初始化事件处理完成。每一个箭头代表这个这些步骤可以同步进行（比如：Recalc Quote和UpdateClaims)。   以上内容即事件驱动架构的调度者拓扑，代理拓扑(Broker topology)将会在下一篇来说明。

2021 年或许是新能源汽车最值得纪念的一年，面对传统燃油车批售量双双下跌的局势，新能源汽车以一己之力为全年乘用车同比增速贡献了 9 个百分点，带动整体市场由负转正。在这之中，渡过融资、生存「至暗时刻」的造车新势力，也终于进入了第一个蓬勃发展年，产品力与销量齐头发展。这一年，「蔚小理」全年车辆交付均超 9 万辆，第一梯队的地位愈发牢靠，同时拉大与第二梯队的差距。其中，仅有理想 ONE 一款车型的理想汽车，无疑成了焦点：它不仅达到 177.4% 的同比增长，12 月还以 14087 辆的交付量，一举超越奔驰 GLC、奥迪 Q5 和宝马 X3。凭借单一车型创下新势力单车交付记录历史新高，并做到正面叫板常年领导 30 万 + 高端 SUV 市场的德系三强，理想 ONE 实际已经开始摆脱新势力、新能源的约束，进入到传统燃油车的主力市场，而这必须要依靠比竞品更强的产品力。在成绩单出炉后，理想汽车创始人、董事长兼 CEO——李想的一条个人微博，引发了热议：「在过去的 2021 年，理想汽车在技术产品交付层面一个最重要变化是智能驾驶…… 在 IPO 之后，理想汽车有了根本的转折，也就是有钱搞技术研发了，而不仅仅做产品研发。」在这条微博的评论区，除了有车主分享自己在实际驾驶中触发 AEB 的有惊无险，也有人提出了理想对 NOA 和 AEB 技术全部自研的疑问。理想汽车为何对全栈自研这条「Hard Way」如此执着，又为何在决定自研后在短时间内就实现了超乎预期的成效呢？这肯定不仅仅是由时代造就的必然。以功能表现为目标的自研按照李想的说法，2021 款理想 ONE 选择自研的最主要原因是要提升安全表现，改用地平线 J3 芯片也是因为其开放性更好，可以支持全栈自研。这个选择与大部分车企不太一样，由于重点不是扩充使用场景和增加功能，前后两版系统之间的关系，是「替代」而不是「升级」。两者差别不容易在传播上体现出来，消费者也难以在购车前感知到。但李想此前一直强调安全的重要性，不管是对于「只有一次出牌机会」、「将安全和质量放在第一位」的理想汽车，还是对于保障理想 ONE 的用户都很重要。这次再选择通过全栈自研，提升智能驾驶的功能表现也并不出乎意料。从结果来看，2021 款理想 ONE 确实是将主要精力放在了原有功能上，重点研发有更多潜力的安全功能，进步最明显的是 AEB（自动紧急制动）。在最近的媒体测试中，2021 款理想 ONE 的 AEB 取得了决赛组第一名的成绩，也是决赛组里唯一有能力准确识别横向车辆和两轮车的车型。实际上，2021 款理想 ONE 做到这点用了一整年的时间，自研的智能驾驶系统在去年分为两个阶段逐步推送，一个是 6 月份交付的基础 ADAS 和基础 AEB 功能，一个是 12 月份交付的 NOA 导航辅助驾驶和完整 AEB 功能。测试中取得第一名成绩的是 12 月的完成版 AEB，去年年中有部分媒体测试 2021 款理想 ONE 后，反馈其 AEB 表现不够出色，也是因为当时的是基础版本。AEB 已经是当下比较常见的辅助功能，很多 10 万级车型也有搭载。理想汽车将 AEB 囊括在自研的主攻方向之中，很有可能变成一件吃力不讨好的事。消费者关注点更集中在从高阶自动驾驶降维而来的功能上，也更愿意为这些功能买单，比如城市辅助驾驶、自动变道等。不过，即使后者进入到较为成熟的阶段，主要用途仍是减轻驾驶压力，而 AEB 则是保障安全、避免事故发生，这也是理想汽车花费精力的自研原因。美国公路安全保险协会 IIHS 早年分析美国 22 个州的交通事故后判断，AEB 可让追尾事故发生概率降低 39%。如今随着 AEB 能力的提升，降低事故的概率还可能更高。此外，2021 款理想 ONE 还新增了 NOA 导航辅助驾驶。如果说仅依靠车端传感器的智能驾驶系统是在靠猜去开车，那么 NOA 就是用提前预知的道路信息，和感知信息做验证结合，安全性、可靠性和体验都更加出色。在有些车企通过将智能驾驶作为软件订阅创造营收的时候，2021 款理想 ONE 仍标配了包括 NOA 在内的全部智能驾驶系统。而据李想透露，未来的车型也会如此：「我们会长期把 NOA 导航辅助驾驶作为标配，因为一家人的安全只有标配，没有选配。」NOA 导航辅助驾驶也因此成为了去年最受欢迎的功能之一，超过 6 万辆车激活和使用过，占比达到 2/3 以上。在 12 月推送的更新里，NOA 导航辅助驾驶还增加了高速路交通事故现场和道路施工现场的识别能力，可以提前给车主提示，进一步保证安全。全栈自研背后的 12 个月理想汽车的自研系统能在去年上车，感觉是很早就规划好了的方案。但实际到 2020 年底，理想汽车才确定所有智能驾驶相关的东西都要全栈自研，之后又用几个月组建完整团队，再分实现基础功能、完善功能两步推送，将自研系统完整落地。外界认为，车企自研初期普遍会走一段下坡路，即使最艰难的从 0 到 1 也只能算是其中一部分，想做到媲美成熟产品的表现，可能还需要数代的积累与优化。这种高成本、长周期的问题，也是车企普遍不敢做全栈自研的原因所在。此前，仅有特斯拉和小鹏两家企业选择做智能驾驶的全栈自研，而理想汽车正是第三家。但理想汽车的自研速度，超过了包括他们自己内在的所有人预料，全程差不多也就 12 个月左右的时间，用于研发的还要更短。这种速度已经不是仅靠加班加点就达到的，还要研发验证流程的创新。以 AEB 为例，「影子模式」和云端数据回传系统是这次高效研发迭代的关键，不仅省时，还有效节省了测试资源。研发团队使用早鸟用户车上的智能驾驶云端数据回传系统，通过「影子模式」让自研的 AEB 软件预埋在车端系统上，用来做测试验证，不会对车辆的控制有任何影响，在 OTA 3.1 前，总计通过众包完成约 1 亿公里的测试验证，相当于传统厂家以及 Tier 1 AEB 道路测试量的 100 倍。同时，基于回传的触发数据，理想汽车还按真实触发、误触发进行筛选，然后再针对不同的问题，拆分到感知、规控等业务模块，去做算法优化。但不同于传统各自独立、自己部门解决自己问题的工作方式，理想汽车这次从问题数据到云端仿真，再到最终的结构呈现，采用了连贯的联合仿真模式，实现功能层面的打通。而在这过程中，理想汽车相比研发速度，仍更重视功能能力，以及要做到更符合中国路况，自研的目标不是 SOP，而是表现更好。作为 24 小时事实待命的系统，更少的反应时间，不仅是更考验判断执行速度、制动能力，也容易对准确率造成影响。为了提高判断结果的准确率，理想汽车采用了多传感器融合的方案，还在行业中首次引入了视觉感知。针对 AEB 主要是对近程目标做判断的需求，理想汽车忽略了视觉感知的距离优势，重点判断目标的位置和运动属性，通过与其它传感器的结果融合，提升判断准确率。理想汽车对 AEB 的思考是，它是一个救命的功能，值得在这方面花费更多功夫。加入视觉感知的 AEB 也不止是准确度的提升，还做到了汽车、自行车、行人的多类型识别。而在包括 2020 款理想 ONE、小鹏等在内的博世毫米波雷达方案中，只能对汽车进行识别，对行人完全无效，这也是理想汽车选择自研的原因之一。理想汽车对于 AEB 的优化和迭代方向的内部考核采用「双轮驱动」的方式，一方面综合 C-NCAP 等测试标准做体系验证，另一方面整理符合中国实际交通状况的相关事故，以优先级对其排列、归类，量化场景难点，设置针对性的攻坚目标。理想内部有一句话，数学成绩好的人，数学能力不一定强，所以不仅需要能通过考试，还要真正能应对实际的真实道路场景。不过，尽管「技术至上」的工程师思维日渐受到推崇，可技术研发的前提仍是「为人服务」。从理想汽车的发展思路可以看出，光有「理工直男」的热情固然不够，对于市场需求的挖掘同样重要。市场需求驱动家庭产品定位除了智能驾驶以外，理想汽车这种不在意噱头，只为结果负责的理念，还贯穿了产品设计的全过程。不同于以新能源汽车要求自己的车型，理想 ONE 还在与传统燃油车进行对比，挖掘并满足用户的真实需求，例如不能有续航焦虑、要将乘坐体验和空间尽可能做好。理想 ONE 当初也因此开拓了 6 座中大型 SUV 的全新细分市场，解决全家出行问题。在此之前，能够保证全家出行空间和舒适度的，几乎只有别克 GL8、东风本田奥德赛等 MPV，但是这些车型使用场景单一、缺乏家用属性，而 7 座 SUV 第三排又普遍鸡肋，导致这部分需求被隐藏。事实上，全家出行已经成为了当下的热门需求之一。不仅是限行、限购、交通和停车等传统问题，导致单车解决全家出行问题的需求增加，疫情实际也在让更多消费者期望通过有封闭空间的私家车出行。市场研究公司 ipsos 此前的调研报告显示，疫情后有 66% 消费者期望使用私家车出行，使用公共交通工具出行的消费者明显减少。随着疫情的基本稳定，自驾游的需求也在复苏。中国旅游研究院发布的《2021 上半年自驾旅游市场趋势报告》指出，2021 年 1-5 月自驾出行人次达到 2.7 亿人次，同比增长 105.8％，恢复至 2019 年同期的 108.1％。但若想用一款车解决全家出行问题，需要同时保证前后排乘客出行体验，甚至给后排乘客提供更好的关照度。强调家庭概念的理想 ONE 无疑是当前市场少有的高契合度车型，其最初的口号就是「创造移动的家，创造幸福的家」，车内布局以空间和乘坐舒适性为主，最终呈现出的结果也很出色，相当是将 MPV 的空间和座椅塞进了 SUV 内。理想 ONE 的大 6 座布局也是由此而来，第二排配备 MPV 标志性的独立电动调节座椅，支持加热 / 按摩功能，同时还给后两排座椅全部配备了 ISOFIX 儿童安全座椅接口，便于家长和儿童座位的合理灵活选择。这种布局也取得了消费者认可，并将之称为奶爸车。根据理想汽车官方公布的数据，2020 款理想 ONE 的用户，超过 96% 都选择了 6 座版车型。因此，2021 款理想 ONE 也取消了 7 座版本，仅推出 1 款 6 座车型。此外，理想 ONE 在实现 MPV 式乘坐体验的同时，还将造车新势力智能化的优势与之结合，前排四屏组合最大化提升人机交互体验，副驾驶屏幕专门服务非驾驶员乘客，供行车时观看娱乐节目。全车共配备了四个拾音器，副驾和后排都可以通过语音指令控制车机系统，提升操作的便利性。针对全家出行的需求，理想 ONE 还提供更多场景化功能，比如，露营时可通过对外放电，给厨具、照明设备、电子产品供电；外接麦克风，可让全家在车内自由 K 歌；小憩模式可一键将调整至最适合躺姿、最适合的温度，并搭配闹铃叫醒功能。依靠对于消费需求的理解与重视，理想汽车仅以一款车型，就稳居造车新势力第一梯队，如今更是做到与传统豪华强者正面对抗。无论是基于产品力，还是市场需求，「出圈」已是理想 ONE 的必然结果。而现在，随着全栈自研智能驾驶系统潜力的释放，理想 ONE 将有更多底气实现新能源和燃油的双线作战。

为什么想写这个，主要是感受到同志们的学习高潮,恨不得各种练习，但又遭遇到一些挑战，比如“我想在项目中推行DDD，但担心其他人不配合”，“DDD门槛太高，概念多”......就笔者之所见，一个标榜实践TDD的项目要不是口号，噱头，要不就失败了，如同要推行DDD的一样。项目不是兵器的练兵场，首先要回到“问题域”，要解决什么问题。一个以推行DDD为目标的项目，总觉得有点慌。就笔者之所见所闻，有1个典型的推广XXX的case。一个是某司的一位空降boss，是一位有创派别的国内“敏捷”专家。当然，敏捷专家几乎都耻于谈敏捷 ，这样也就和其他人谈的“敏捷”无法区分开去。空降boss一来就感觉到这个团队在代码匠艺 、发布、甚至设计抽象都存在某些不足，于是大谈敏捷实践和各种老外前辈云云，但却被团队吐槽，因为那会这群码农最关心的是“生存问题”，去总部找活回来干的问题 。几个月后这位boss转变了思路，通过抓稳定迭代的release，促进快速反馈“挽尊”，此是后话。这个case，让人懂得了 一个道理，一位病人发烧了，医生可以先采取措施让他退烧，然后治疗。病人并不喜欢医生跟他讲中西医区别，药理知识。第二个道理就是，鸡蛋好吃，你非要去分辨是那只鸡下的蛋，并无多大必要。团队员工的期待是空降老板给我们指方向，找活干，加薪而不是推广敏捷 。同理，江湖上流传着这样的说法：老板看问题的视角是，“这个需求很简单，怎么实现我不管”。某些技术人员的视角可能是，“十八般武艺都用，至少面试用得着”。另外很诡异的一个点在于，人类对于所谓 “建议”往往听不进去，然后总会找到一堆来证伪，然后又乐此不彼的“学习着”，争论他认为对的观点...笔者自己也做过推广XXX的事情，持续集成。这东西大家都知道，我们之前有一个简单的规约，就是每天下班前的构建要绿色 ，单元测试和接口测试都得通过。好些同学怨声一片，代码都写不完，干嘛还要去写测试代码？尤其是之前测试代码覆盖率巨低的系统，几百个测试case不通过的系统 ......采取简单粗暴的每天强制的方式，存量用例设定计划治理，研发同学不情愿的被要求每天跑CI......在大显示屏的曝光和强迫之下，持续了半年多... 后来有项目团队主动分享CI带来的好处，测试代码在他们后面的重构过程中发挥了作用，心里有底多了。这个故事让我“自以为是”的懂得了第二个道理，让人懂得或者转变是很难的，猴子自己上树和抽猴子屁股上树的区别。如果你拿着香蕉在猴子面前晃，就不一样了。 Greg Young 先生有一个presentation ，主题就是“7 Reasons Why DDD Projects Fail“，简单总结DDD 失败的要点：Lack of intent（缺乏意图）Anemic Domain Model（贫血模型）DDD-LiteLack of isolation （缺乏隔离）Ubiquitous what?Lack of refinement（缺乏完善）Proxy Domain Expert (Business analyst)   笔者稍微谈一下自己的理解。1、首要解决通用语言UL(Ubiquitous Language问题，统一域语言。张逸老师指出，统一语言是提炼领域知识的产出物，获得统一语言就是需求分析的过程，也是团队中各个角色就系统目标、范围与具体功能达成一致的过程。使用统一语言可以帮助我们将参与讨论的客户、领域专家与开发团队拉到同一个维度空间进行讨论，若没有达成这种一致性，那就是鸡同鸭讲，毫无沟通效率，相反还可能造成误解。因此，在沟通需求时，团队中的每个人都应使用统一语言进行交流。可以想象一下，做支付、银行、电商行业的朋友在谈及记账、清算、结算、核算这些词的时候是否是一个明确统一的含义。一旦确定了统一语言，无论是与领域专家的讨论，还是最终的实现代码，都可以通过使用相同的术语，清晰准确地定义领域知识。重要的是，当我们建立了符合整个团队皆认同的一套统一语言后，就可以在此基础上寻找正确的领域概念，为建立领域模型提供重要参考。2、没有基于通用语言建立的所谓的聚合，实体，值对象，只能算是DDDLite，只是技术层面的一种设计方式。3、要解决好隔离问题，则需要以一种最宏观的角度去对“问题域”进行拆分，来划分“界限上下文”，最终形成一个具有俯瞰视角的“上下文映射图”。这里特别说一下“界限上下文”和问题域、以及服务谁，产生什么价值息息相关。比如一个采用第三方支付（支付宝）的网站，并不对支付宝背后的网联，以及银行渠道进行建模。4、refinement的问题架构腐化见怪不怪，如何领域层腐化了就“烂到跟上”。笔者见过一个系统，初期磨拳搽掌，建造者经验丰富，算是很成功的开端。但是若干年后这个系统domain层的代码和当初的领域模型图大相径庭，面目全非。持续的refinement、保鲜非常重要。另外，前几天和一位TL聊天，他说，我很注重代码追求的，为什么1年多我没怎么看代码，他们完全不是按照我想象的样子在写代码。

本人大三，专业为教育技术学，在浏览阿里云页面中发现了“飞天加速计划·高校学生在家实践”，可惜并没有很早的发现，错失了免费试用一年的机会。但现在的“飞天加速计划”依然十分有吸引力。阿里云ECS的CPU核心数、硬盘大小、带宽等可曾可减。可以根据网站运营状况，灵活调整服务器配置，方便很多。更可以直接使用有宝塔的Linux镜像,进而简化服务器管理，十分便捷，使用宝塔，GUI界面减少了了Linux命令行易出错的问题，人机交互跟加明显，同时，ECS还可以根据需求更换不同的操作系统，包括不同的Linux/Windows操作系统以及各个版本，灵活而且免于繁琐的环境配置以及网络管理，轻便、有效。很容易就可以搭建起一个基于php,ngix,mysql,wordpress的简易页面，而且在Linux中可以使用vim，大大提升了文本输入的便捷性。唯一需要注意的是各个服务所需要使用的端口，在ECS中启用新端口需要在安全组中添加新的策略，或者直接更换全开的安全组（安全性欠佳），否则无法访问。总的来说，在这次体验中体会到了ECS的诸多优秀特性,稳定、弹性、高安全、高性能、易用、高拓展等等。最后，还是要感谢阿里云飞天计划能够免费提供大学生一台云服务器，这真的对学生的学习有很大的提高，无论是对Linux操作系统的认识，还是对各种协议端口的认识，都让我本身有了很大程度上的提高，也让我能为以后的学习做好铺垫。当然我还是一个初学者，之后还有很长的路要走，感谢“飞天加速计划·高校学生在家实践”这个活动，让我在学习的道路上有了新的方向，新的目标，并为之向前进。

本人大三，专业为教育技术学，在浏览阿里云页面中找到了该活动，可惜并没有很早的发现，错失了免费试用一年的机会。阿里云ECS可以接入宝塔Linux,进而简化服务器管理，十分便捷，GUI界面免去了Linux命令行易出错的问题，人机交互跟加明显，同时，ECS还可以根据需求更换不同的操作系统，包括不同的Linux/Windows操作系统以及各个版本，十分灵活而且免于繁琐的环境配置以及网络管理，轻便、有效。而且在ECS中可以使用vim，大大提升了文本输入的便捷性。在Linux中结合宝塔构建网页服务也方便很多。唯一需要注意的是在ECS中启用新端口需要在安全组中添加新的策略，或者直接更换全开的安全组（安全性欠佳）。总的来说，在这次体验中体会到了ECS的诸多优秀特性,稳定、弹性、高安全、高性能、易用、高拓展等等。

领域模型=ER？领域模型是否就是ER模型呢？答案是否定的，领域模型是特定业务域业务实体关系的自然浮现，而ER是设计阶段数据库实现关系的产物。如下图所示，自然人Person在特定业务领域有2类，一类是客户（Customer），一类是雇员(Employee).但究其实现而言，数据库设计有多种形态。领域建模=DDD？一说领域建模就提及DDD, 是大家的自然反应。因为DDD（2004年著名建模专家EricEvans发表了他最具影响力的著名书籍：Domain-Driven Design –TacklingComplexity in the Heart of Software）的知名度颇高。我的观点是领域模型的产生是分析阶段的产品，分析是对需求及需求背后相关内容的挖掘，不用创造内容。DDD顾名思义是模型驱动设计，是从需求打通到设计阶段的方法。领域建模涉及到哪些概念呢？域（domain）：需要讨论的问题范围，称为域或者问题域。子域（subdomain）：对于域进行不同纬度切分相对内聚的单元。比如电商业务涉及订单、库存、营销子域等。语境（context）：是一个特定人群在讨论的问题域是所形成的上下文。 这里要强调一个概念，特定人群不是以团队或者是项目为边界划分的人群， 而是以知识为边界来划分的人群。 也就是说上下文不是普遍存在的， 而是存在于一个人群内部的，并且这些上下文大多是以隐形知识（Tacit Knowledge）的方式而存在的。域语言（Ubiquitous  Language）： 领域模型可以成为大家沟通公共语言的核心，同时将团队沟通与软件实现紧密联系到一起。这种公共语言是整个团队工作中的UBIQUITOUS LANGUAGE（通用语言）。实体(Entity)：实体就是领域中需要唯一标识的领域概念。因为我们有时需要区分是哪个实体。有两个实体，如果唯一标识不一样，那么即便实体的其他所有属性都一样，我们也认为他们两个不同的实体；因为实体有生命周期，实体从被创建后可能会被持久化到数据库，然后某个时候又会被取出来。所以，如果我们不为实体定义一种可以唯一区分的标识，那我们就无法区分到底是这个实体还是哪个实体。数值对象（Value Object）：  值对象没有唯一标识，这是它和实体的最大不同。有一部电影中说联邦调查局通过隐私查询，查询到男主和女二曾在大学期间拥有相同的收货地址而判断他们曾住在一起。这里的Address可以作为值对象，它的所有属性决定它是谁，而不必通过ID来区别。触发事件（Event）：企业级应用程序事件大致可以分为三类：系统事件、应用事件和领域事件。领域事件的触发点在领域模型（Domain Model）中，故以此得名。通过使用领域事件，我们可以实现领域模型对象状态的异步更新、外部系统接口的委托调用，以及通过事件派发机制实现系统集成。在系统分析阶段，我的观点是不区分事件类型。思考 Event与彩色建模中的MI有无区别和联系？在电信信息架构中有大量的事件，如下图所示。观点：不建议在分析阶段区别Entity和Value Object不建议在分析阶段区别Entity和Value Object。比如Customer和Adress的关系和区别一样，在后续精细化过程中，认识自然就清楚了，比如Adress是可以复用的，非唯一的。观点：在域模型中可以增加业务规则作为补充在域模型中可以增加业务规则作为补充。比如下图在送货单和订单项的关系上有一行约束说明：只有当所有订单项都已经送到，才能成功关闭订单。我们来看看 DDD的内容那些是领域建模（分析阶段应该识别的）。如上图所示，在分析阶段可以用的至多有entity、value object。再次论证了DDD是一个重在Design的工具。基于上面域，域语言等概念，不难理解不同域同一名词的含义不同，即使是同一介质它的内涵和外延也不同，我们可以把域表述为问题域。比如电子商务网站有优惠券，包括天猫购物券、店铺券、商品优惠券等，下图为淘宝券截图。还有一个专门做券导航的网站：券妈妈。这2个网站管理的券是同类的东西，它们的模型是否就一样了呢？这2个网站管理的都是券，但是业务实体[券]是有差异的，因为它们要解决的问题域不同。券妈妈是一个流量入口，关注领用和跳转；而淘宝券关注使用情况[下单时订单金额扣减]，包括使用券的用户对店铺的黏性，二次消费等。业务实体的业务行为，状态也有有所差异。问题域vs问题解决域最后总结一下，问题域和问题解决域是2个范畴，分属分析、设计及实现阶段，在不同阶段使用的工具和目标也有所差异，如下图所示：在分析阶段的领域模型中，我觉得主要描述领域实体及关系，可以辅助领域名词解释（可以是业务字典形式）、以及约束（业务规则），而业务实体（域实体）仅描述主特征即可。未完待续，领域建模刍议（二）将介绍建模的方法体系。ps: 系统化思考是最好的总结和学习，我在编写本章的过程中发现了一些模糊的内容，包括写完也有不少未知。ps：长期使用java语言，近几个月发现.net领域不乏对于领域的深入思考者。特别推荐：汤雪华，网名netfocus，2006年毕业于浙江大学，目前住在杭州。对DDD，以及CQRS架构比较感兴趣。开源软件ENode负责人，现就职阿里巴巴。文章中关于entity的描述参考了汤老师的下文http://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html陈晴阳（Sunny Chen），2003年毕业于中南大学铁道校区。高级程序员，系统分析员，微软MVP（Visual C#）。cnblogs网名daxnet，并打算以该名闯荡IT江湖。MicrosoftDynamics AX、Microsoft .NET/C#以及领域驱动设计（DDD）的狂热爱好者。文中关于Domain Events的描述引用自http://www.cnblogs.com/daxnet/archive/2012/12/27/2836372.htmlps：集团内阿白对于界限上下文（Bounded context）、语境映射（Context Mapping）以及域语言（Ubiquitous  Language）均有非常精彩的论述。本文作为外网公开使用，去除了相关引用，特此说明。ps：现居于成都的老司机张逸大师对于领域建模也颇有卓见，此前有些公众号文章讨论。