微服务（微服务架构）和DDD（领域驱动设计）是时下最火的两个技术名词。在过去两年的咨询工作中，我总是被不同的团队和角色问到，这也促使我思考为什么这两个专业名词会如此深入人心。他们之间是什么关系？ServingHigherbusinessresponsiveness首先，从这两个词的发明来看，它们没有因果关系。DDD是EricEvans在2003年出版的书名，也是这种架构设计方法名称的由来。DDD的思想是使我们的软件实现与从我们的业务需求派生的不断发展的架构模型保持一致。这种进化的设计方式在当时看来颇具挑战性。目前比较流行的解决架构设计复杂性的方法是分层：如数据架构、服务架构、中间件架构等。MVC在互联网应用开发领域基本已经成为标准。快进10年，MartinFowler和ThoughtWorksUK架构师JamesLewis坐下来分析了几个可以持续演化的大型复杂系统，总结出9个核心特征，然后用微服务来定义这些特征。建筑学。后来，随着谷歌、Netflix、亚马逊等一系列明星公司纷纷入席，微服务开始席卷整个软件行业。这时候很多人就会问微服务架构是怎么设计的。业内人士会说DDD是个好方法，包括微服务定义者MartinFowler。毕竟是他给DDD原书作了序，所以DDD定义10年后才开始流行起来。以我个人的观点，如果真要找因果关系，最根本的驱动力来自于科技时代对软件系统（数字化）响应性要求的不断提升，而系统的复杂性是随着业务的多元化而增加。并且一天比一天增加。如何管理如此高的复杂性成为每个企业必须面对的挑战，以至于业界开始将这种模式概括为响应型企业（ResponsiveEnterprise），而该模型总结的大部分原则都是为了更好地适应高环境不确定性带来的复杂性。从业务角度分离复杂性每个人能认识到的复杂性是有限的。面对高度复杂的时候，我们会分离关注点，这是最基本的哲学原则。显然，我们在对复杂的业务场景进行建模时也应用了这一原则。这时候关注点的分离一般可以从两个维度入手：技术维度的分离，像MVC这样的分层思想被我们广泛接受。业务维度分离，按照售前、售中、售后等不同业态划分系统。以上两个维度没有区别。它们将在处理复杂问题时使用。但是，为了高效响应业务变化，微服务架构在业务维度强调关注点分离，以应对高复杂度。这是与传统SOA架构明显不同的特点之一。比如传统SOA时代诞生的ESB（IndustrialServiceBus），就是典型的脱离技术关注点的中间件。随着业务的变化，我们也看到ESB已经成为一种架构反模式，即大量的业务规则和流程被封装在ESB中，使得ESB成为不可控复杂性的来源，以至于破坏了之前的各种优势SOA架构所承诺的。当然，微服务架构不像新一代的SOA架构那么简单。讨论这个话题的文章已经很多了，本文就不展开了。因此，从本质上讲，DDD作为一种架构设计方法和微服务作为一种架构风格，都是从业务角度分离复杂性以追求高响应性目标的手段。如果在这个时代你还觉得你的架构不需要这种响应式，我建议你去问问你维护系统3年以上的朋友或者同事，他们会告诉你这是一种什么样的痛苦。事实上，很多企业已经“疯狂”地追求这种响应式，而这可能是微服务的两位定义者所没有想到的。他们在定义文章中有着强烈的警告语气，提醒大家谨慎使用，但在这个技术时代，微服务架构实施可能带来的风险，相比于未来高响应性可能带来的市场机遇，几乎可以忽略不计。一个Netflix的成功，足以让大部分企业毫不犹豫地选择微服务作为自己的架构风格。逐步统一业务和技术的架构设计如果微服务和DDD在目标上实现了以上的统一，那么具体的做法和之前有什么区别呢？为了把这个问题说清楚，我们把架构设计简化为以下三个层次工作：业务架构：根据业务需求设计业务模块和交互关系。系统架构：根据业务需求设计系统和子系统的模块。技术架构：根据业务需求确定采用的技术和框架。显然，这三者在一个具体的架构设计活动中应该是先后顺序，但不一定是第一个。比如一个简单的web应用，很多人会说MVC是标准的（先确定系统架构），或者有人说用RoR更快（先确定技术架构）。在给定的业务场景中，也许这样的顺序是合理的。（架构设计工作的分层和传统意义上的负责人）这个时候我们加入两个环境变量，复杂的业务需求和快速的市场变化，这个序列就变得很有意思了。于是我们听说很多走出创业期的互联网服务平台开始“重写”自己的系统（从PHP到Java），很多文章开始反思MVC带来的死板（臃肿的表现层）.经历过这种变化的架构师会对DDD平台感同身受。原因在于，“跳过”（或“替代”）业务架构，很明显表明设计架构的重点不在业务的响应能力上，因为没有分析业务可能的变化点来指导设计系统和技术架构。DDD的核心诉求是让业务架构和系统架构形成一种绑定关系，从而当我们针对业务变化调整业务架构时，系统架构也会自发发生变化。这种变化有两个结果：业务架构的梳理和系统架构的梳理是同步和渐进的，结果是划分的业务上下文和系统模块结构绑定。技术架构解耦，可以根据划分的业务上下文的系统架构选择最合适的实现技术。第一点显然是我们在生成微服务划分时必须遵循的，因为微服务追求的是业务层面的复用，所以设计出来的系统一定要和业务保持一致。第二点是微服务架构的特点：“去中心化”的治理技术和数据管理。作为一种架构设计的方法，DDD的各种实践，包括最近流行的EventStorming（事件风暴），其实都是对业务和系统架构的推进认知。在一个DDDworkshop上，有同事给出了这样一句经典的评论“你连业务故事都讲不出来，还有必要继续做架构设计吗？”DDD的整个方法不涉及具体技术架构的实现，选择模型的权利往往“下放”给真正的开发团队。值得一提的是，DDD的架构设计方式并不一定会产生Mircoservices的架构风格。通常建议使用大粒度的服务，将业务分析过程中发现的不确定点包含在内，避免拆分后的变更频率过高带来的双向修改成本。跨职能协作的架构设计对业务和系统的逐渐认知，改变了以往很多架构工作模式。在采用DDD的过程中，很容易感受到业务专家的重要性。而如果还有人希望业务能一次把需求讲清楚给架构师，那我建议有这种希望的同学去参加一个自己不熟悉的业务领域的架构设计讨论.你很容易得出“原来业务不明白他想要什么”的结论。当然，业务人员听到要参与某种（软件）架构设计方法，肯定是有抵触情绪的。DDD成功应用的基础是创造一个逐渐统一业务和系统两种不同认知模型的环境。（业务架构和系统架构设计）所以“不幸”如果你不能建立一个新的跨业务和技术的架构设计团队，你的DDD实践就没有成功的基础，那么采用微服务架构可能就是一场战败。幸运的是，这种跨职能的组织结构已经是上一篇文章中“采用”微服务架构的企业（比如亚马逊）的标准配置，你不需要论证这件事的实用性。剩下的关键是如何让来自不同背景的人能够协作。这也是大家能看到的下一个DDD领域的热点。越来越多像EventStorming这样的模块化协作工作坊将出现在你的视线中。永无休止的DDD和不断发展的MicroservicesDDD令人上瘾。当大家发现，通过这个建模过程，业务专家更了解业务划分（系统模块），架构设计更了解业务需求。这种合作将成为常态。在这个tech@core时代，这种融合将成为企业的核心竞争力。当然，当你刚开始使用DDD方法时，请不要以为每个系统都做一个所谓的DDDworkshop就可以找到最好的服务部门。业务变化是连续的，业务架构的每一次变化都不可避免地影响到系统架构的变化。一个好的领域架构将业务和系统绑定在一起，让双方的人员可以用统一的语言进行交流。建立起来不易，持续经营更难。DDD方法的成功应用贯穿于系统的整个生命周期，业务与技术的协同在此过程中不断发生。微服务的最后一个特征：“进化”设计——也明确表明设计是一项持续的活动。DDD提供了一种符合这种微服务特性的工作方式，让进化落地。值得一提的是，根据笔者最近的经验，在这个演进过程中最难认识和改变的是DDD中最明显的“统一语言”。当每个人都形成一个商业概念——“客户”时，很少有团队能够不断审视这个“客户”的含义是否随着市场的变化而发生了变化。与传统SOA相比，微服务的拆分也是动态的。居文静在她的文章中描述了在系统采用微服务架构的过程中服务拆分的演变过程。不会有放之四海而皆准的ESB，而且这种幻想在过去10年中已多次破灭。DDD的好处是业务和技术人员在合作中都能理解这种变化，不至于陷入业务人员抱怨技术架构无所谓，技术人员觉得业务人员别扭。你得长那么高！MartinFowler在他的微服务定义文章中画了下图，评论“你必须那么高”作为微服务实现的能力需求的隐喻。就架构建模而言，我觉得DDD应该是一个团队必须掌握的，包括团队的业务人员和产品设计师。（表示微服务的前置条件）很有意思的是，ServiceDesign也是目前全球用户体验设计领域的一个热门话题，整个服务链都是从用户的角度来设计的。比如时下流行的共享单车，一个成功的服务设计应该是从用户对汽车的需求，到最终完成骑行和支付的触发，而不仅仅是设计一辆可以通过互联网解锁的自行车。我们可以发现ServiceDeisgn和DDD在原理上有很多相似之处，比如以用户为中心，协同设计。借用上面那个高个子：业务需求认知和跨职能协作一定要高大上！】点此查看作者更多好文
