我认为，要想应用 DDD，首要任务就是要吃透 DDD 的核心设计思想，搞清楚 DDD、微服务和中台之间的关系。中台本质是业务模型，微服务是业务模型的系统落地，DDD 是一种设计思想，它可以同时指导中台业务建模和微服务设计，它们之间就是这样的一个铁三角关系。DDD 强调领域模型和微服务设计的一体性，先有领域模型然后才有微服务，而不是脱离领域模型来谈微服务设计。
2.实现方式：DDD 分层架构、整洁架构、CQRS 和六边形架构等 （我们采用DDD 分层架构）
当前对领域事件的定义：领域专家所关心的发生在领域中的一些事件。将领域中所发生的活动建模成一系列的离散事件。 每个事件都用领域对象来表示，领域事件是领域模型的组成部分，表示领域中所发生的事情。
将领域中所发生的活动建模成一系列的离散事件。每个事件都用领域对象来表 示……领域事件是领域模型的组成部分，表示领域中所发生的事情。 一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环。
领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。领域可以拆分为多个子领域。一个领域相当于一个问题域，领域拆分为子域的过程就是大问题拆分为小问题的过程。
除了命令和操作等业务行为，还有一种非常重要的事件，这种事件通常会导致进一步的业务操作，在DDD（Domain Driven Design，领域驱动设计）中，这种事件叫做 领域事件。
引言 | 本文作者从微信团队维护的带货类项目所遇卡点出发，尝试用领域驱动设计方法（简称DDD），保障在快节奏、多人协作的项目迭代中，维持系统的可维护性、可拓展性、高内聚低耦合和稳定性。作者首先剖解相关概念原理，之后代入亲身参与的微信团队实际项目、围绕DDD方法进行优化实操。 DDD 全称 Domain-Driven Design，中文叫领域驱动设计，是一套应对复杂软件系统分析和设计的面向对象建模方法论。它由Eric Evans于2003年提出，但一开始不愠不火。直到MartinFowler于2014年发表论
导读：本文来源于 2020 年第四届 DDD 中国峰会主题演讲：《当中台遇上 DDD，如何设计微服务》。DDD 非常强调统一语言，而 DDD、中台与微服务产生于不同的时代，三者分别属于不同的方法体系，而方法论的融合首要在于建立统一语言，那么：
本文将讨论微服务与 DDD 涉及到的概念、策划和设计方法，并且尝试将一个单体应用拆分成多个基于 DDD 的微服务。
软件设计首要面对的挑战是如何应对复杂多变的业务问题。而对于业务中台来说，这个问题变得尤为突出。一方面，数字化时代，高度不确定并且快速变化的商业环境必然要求企业的业务也能够及时快速的响应，业务复杂度随之也越来越高；另一方面，业务中台作为企业级能力承载与共享的中台，它是要把大部分业务能力积累沉淀为上层应用能够共享复用的能力池。如何识别与隔离业务中的变与不变，保持复杂度总体可控，并使业务中台架构如实地与业务保持演进，是业务中台构建的关键。
你是否还在为微服务应该拆多小而争论不休？到底如何才能设计出收放自如的微服务？怎样才能保证业务领域模型与代码模型的一致性？或许本文能帮你找到答案。 本文是基于 DDD 的微服务设计和开发实战篇，通过借鉴领域驱动设计思想，指导微服务项目团队进行设计和开发（理论篇详见《当中台遇上 DDD，我们该如何设计微服务？》）。本文包括三部分内容：第一部分讲述领域驱动设计基本知识，包括：分层架构、服务视图、数据视图和领域事件发布和订阅等；第二部分讲述微服务设计方法、过程、模板、代码目录、设计原则等内容；最后部分以一个项目为例讲述基于 DDD 的微服务设计过程。
尽管微服务中的“微”一词表示服务的规模，但它并不是使用微服务的唯一标准。当团队转向基于微服务的架构时，他们旨在提高敏捷性以及自主且频繁地部署功能。很难确定这种架构风格的简单定义。我喜欢Adrian Cockcroft的关于微服务的简短定义：“ 面向服务的体系结构，它由松散耦合的、具有上下文边界的元素组成。”
微服务中的术语"微"传达了一个服务的大小，但这不是将一个应用变为微服务的唯一准则。当团队转变到基于微服务的架构时，需要提高敏捷性(自动部署和频繁发布)。很难对微服务架构的风格做一个准确的定义。我倾向于Adrian Cockcroft 的定义："由松耦合且具有边界上下文的元素构成的面向服务的架构"。
DDD诞生的主要目的是为了解决业务复杂度，DDD本身不要求你的系统架构必须采用服务化或者微服务。他更像一种方法论或心法，其与具体技术实现无关，但会对你领域划分起到理论支撑的作用。
DDD 是什么，DDD 的英文全称是 Domain-Driven Design，翻译过来就是领域驱动设计。
今天这篇，我们主要分享应该如何定义一个微服务架构，怎么定义一个服务，微服务架构究竟又应该怎么进行服务拆分。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
领域驱动设计中定义了超多的概念，如果不多找几篇资料综合的去看，正确的理解比较困难，下面搜集整理了大部分的领域驱动中的概念，并加以理解描述。
微服务架构模型有好多种，例如整洁架构、CQRS和六边形架构等等。每种架构模式虽然提出的时代和背景不同，但其核心理念都是为了设计出“高内聚低耦合”的架构，轻松实现架构演进。而DDD分层架构的出现，使架构边界变得越来越清晰，它在微服务架构模型中，占有非常重要的位置。
随着微服务架构的兴起，微服务设计与拆分的的最佳实践DDD已然成为大家讨论与实践的热点，整个行业都在探索如何用DDD建模来实现微服务设计。事件风暴作为最接地气的实践，在不同的项目中野蛮生长，不断演进，今天已经渐渐成熟。作为事件风暴的灵魂——领域事件，值得我们投入更多的精力去设计与打磨。
分层架构设计就是为了帮助我们达到高内聚、低耦合复用性设计和扩展性设计。整洁架构、CQRS、六边形架构等微服务架构都旨在实现“高内聚低耦合”，而分层架构基本原则是每层只能与位于其下方的层发生耦合。分层架构又分为两种：
原文地址：https://dzone.com/articles/visualizing-microservices-designing-a-microservice
在前面一篇介绍了如何通过DDD的思想，来调整单体服务内的工程结构，为微服务的拆分做准备。同时介绍了我们在进行微服务拆分的时候踩过的一些坑。 这篇介绍下我们最终的方案，不一定对，欢迎留言讨论。
微服务架构已经成为现代应用程序开发中公认的技术选择。尽管它解决了某些问题，但不是灵丹妙药。它有几个缺点，使用这种体系架构时，还需要解决许多问题。这就需要学习这些问题的通用模式，并通过可重用的解决方案来解决它们。因此，有必要讨论微服务的设计模式。在深入研究设计模式之前，我们需要了解微服务架构的构建原理： 1.可扩展性 2.可用性 3.弹性 4.独立自治性 5.去中心化治理 6.失败隔离 7.自动配置 8.通过DevOps持续交付
我们先不讨论DDD的定义， 先梳理一下DDD火起来的背景， 根据我学习的套路， 永远是为什么为先，再是解决什么问题，是什么东西， 最后如何使用。我们都知道这些年随着设备以及技术的发展，软件架构发生了很多变化，从最初的单机(BS/CS)架构到后面的集中式架构，再到如今的微服务架构。
我们先不讨论DDD的定义， 先梳理一下DDD火起来的背景， 根据我学习的套路， 永远是为什么为先，再是解决什么问题，是什么东西， 最后如何使用。我们都知道这些年随着设备以及技术的发展，软件架构发生了很多变化，从最初的单机(BS/CS)架构到后面的集中式架构，再到如今的微服务架构， 现在基本可以说是微服务架构盛行的时代， DDD早在2004年就由埃里克·埃文斯提出， 但一直处于一个不愠不火的状态，直到Martin Fowler的《Microservices》引起大家注意， 也就是微服务盛行之后(这儿需要说明的是，微服务最早的提出者不是Martin Fowler，而是Fred George)， DDD再次回到人们视野中间，为什么呢 ？
我们先不讨论DDD的定义， 先梳理一下DDD火起来的背景， 根据我学习的套路， 永远是为什么为先，再是解决什么问题，是什么东西， 最后如何使用。
稍微回想一下计算机硬件的工作原理我们便不难发现，整个计算机的工作过程其实就是一个对事件的处理过程。当你点击鼠标、敲击键盘或者插上U盘时，计算机便以中断的形式处理各种外部事件。在软件开发领域，事件驱动架构（Event Driven Architecture，EDA）早已被开发者用于各种实践，典型的应用场景比如浏览器对用户输入的处理、消息机制以及SOA。最近几年重新进入开发者视野的响应式编程（Reactive Programming）更是将事件作为该编程模型中的一等公民。可见，“事件”这个概念一直在计算机科学领域中扮演着重要的角色。
互联网电商平台和传统核心应用，两者面向的渠道和客户不一样，但销售的产品却很相似，它们之间的业务模型既有相同的地方，又有不同的地方。
本文主要探讨了微服务架构的优缺点，以及作者在使用微服务架构过程中遇到的问题。作者通过分析微服务的定义、发展历程、以及其与SOA之间的关系，使读者对微服务有一个初步的了解。同时，文章也探讨了微服务的几个典型架构，以及在使用微服务过程中可能遇到的问题。最后，作者提出了微服务的几个设计原则，以及在使用微服务架构时需要注意的一些问题。
最早是在极客时间知道欧创新老师的，我也是他的课程《DDD实战课》的订阅者，后来欧老师基于这门课程做更多的实践与思考，完成了《中台架构与实现：基于 DDD 和微服务》这本书的写作，最近刚好读完了这本书。
微服务架构已成为现代应用程序开发的事实上的选择。虽然它解决了某些问题，但它不是灵丹妙药。它有几个缺点，在使用这种架构时，必须解决许多问题。这就需要学习这些问题中的常见模式并用可重用的解决方案来解决它们。因此，需要讨论微服务的设计模式。在深入研究设计模式之前，我们需要了解微服务架构的构建原则：
在前面的两篇文章中，笔者给大家介绍了DDD核心思想、重要概念以及如何进行DDD进行微服务实践的大致过程，后续的文章中将逐渐深入DDD的实践细节，包括领域模型与代码模型的映射以及具体的微服务设计实例等。当下微服务盛行，微服务架构解决了单点系统的可用性问题、突破单节点服务的性能瓶颈同时提升了整个系统的稳定性。因此各大公司纷纷转向微服务架构，但是在实际的微服务拆分过程中也会遇到不少的问题。而DDD中的领域模型构建以及边界上下文的划分天然的和微服务划分有着异曲同工之妙，因此结合DD领域驱动设计来进行微服务拆分是一种比较好的微服务拆分方案。那么今天就和大家聊聊怎么进行微服务拆分。
在学习 DDD领域驱动设计 的过程中，这种方法包括特别的抽象概念，晦涩难懂，本文结合作者理解，对其方法论中的一些概念进行解析。
通过前面的文章介绍，相信大家对于什么是 DDD 有了初步的了解，知道它是一种微服务的架构设计方法论，为我们解决如何建立领域模型，如何实现微服务划分等提供了方向和指导。但是对于如何具体落地使用 DDD，可能大家还是一脸懵 B 的状态，因此从本文开始以及后面的文章将对如何进行 DDD 落地进行详细的阐述。在这其中还是会涉及到 DDD 中的一些重要概念，原本想着在一篇文章中介绍所有的概念，但是我觉得，概念总是在它该出现的时候出现才会让大家印象深刻，否则这些概念只是死板的概念，我们不清楚他为什么出现以及可以解决什么问题。
- 什么是通用语言 - 通用语言， 最主要的目的就是减少交流中信息丢失， 在实际开发中, 可能关联很多人, 例如有业务层面的业务细节制定者、领域专家、产品经理、项目经理 、架构师、开发
刚刚结束的2019年领域驱动设计峰会（DDD China Conference 2019），已经是DDD-China的第三年了，也是我参加的第二年，还记得去年分享的是《当我们谈中台时我们在谈些什么》，讲的更多是中台的Why和What，转眼间一年就过去了，弹指一挥间。
欢迎继续关注本系列文章，下面我们继续讲解下DDD在实战落地时候，会具体碰到哪些问题，以及解决的方式有哪些。
DDD并没有给出标准的代码模型，不同的人可能会有不同理解。 按DDD分层架构的分层职责定义，在代码模型里分别为用户接口层、应用层、领域层和基础层，建立了 interfaces、application、domain 和 infrastructure 四个一级目录。
比起“高并发、多线程”、“分布式CAP、一致性、Paxos”、“高可用SLA”等具体的干货技术点，软件体系知识显得很“湿”，似乎人人都有自己的认识，但又很少有人能说完整。
理查森：我是克里斯·理查森。欢迎来到我关于在微服务架构中最小化设计时耦合的演讲。在这次演讲中，我将回答三个问题。什么是设计时耦合？这会造成什么问题？我们如何设计松散耦合的服务？这些年来我做了一些事情。最值得注意的是，我写了一本书《POJOs in Action》我创建了最初的CloudFoundry，它是用于在AWS上部署Java应用程序的PaaS。这些天，我专注于微服务架构。我写了一本书，“微服务模式”我通过咨询和培训帮助世界各地的组织成功地采用和使用微服务。
稍微回想一下计算机硬件的工作原理我们便不难发现，整个计算机的工作过程其实就是一个对事件的处理过程。当你点击鼠标、敲击键盘或者插上U盘时，计算机便以中断的形式处理各种外部事件。 在软件开发领域，事件驱动架构（Event Driven Architecture，EDA）早已被开发者用于各种实践，典型的应用场景比如浏览器对用户输入的处理、消息机制以及SOA。最近几年重新进入开发者视野的响应式编程（Reactive Programming）更是将事件作为该编程模型中的一等公民。可见，“事件”这个概念一直在计算机科学
如今，微服务架构已经成为了现代应用开发的首选。虽然它能够解决大部分的程序问题，但是它并非一颗百试不爽的“银弹”。
该架构最主要原则：依赖原则，它定义了各层依赖关系，越往内依赖越低，代码级别越高，能力越核心。外圈代码依赖只能指向内圈，内圈无需知道外圈任何情况。
看标题感觉这个东西很理论，比起“高并发、多线程”、“分布式CAP、一致性、Paxos”、“高可用SLA”等具体的干货技术点，软件体系知识显得很“湿”，似乎人人都有自己的认识，但又很少有人能说完整，有一点可以确定的是，如果你未来需要独立设计一个复杂的系统中台，并使之未来能快速应对各种需求变化的话，科学合理的领域划分和边界界定需要我们“处女座级”的坚持下去，这对防止人力失控、减少项目烂尾很有帮助。合理的界定了边界后，即便某个微服务很糟糕，也可以就输入输出以很少的人力投入进行重构，相反的就是牵一发而动全身，加上业务需求频繁而来，很容易烂尾或是达不到如期的效果。
过去几年，通天塔一直处于快速的业务能力建设和架构完善的阶段，以应对不断增长的业务需求和容量、高可用等技术需求，现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力，主流程的新需求越来越少，个性化需求和非标准化流程的数据源和服务接入的需求越来越多，有些甚至是京东零售体系外的，同时通天塔技术和产品也在积极主动寻求变化和创新，这些因素结合在一起驱动通天塔孵化出了一个以技术为导向的项目：通天塔积木，旨在构建一个基于完全开放的前端
过去几年，通天塔一直处于快速的业务能力建设和架构完善的阶段，以应对不断增长的业务需求和容量、高可用等技术需求，现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力，主流程的新需求越来越少，个性化需求和非标准化流程的数据源和服务接入的需求越来越多，有些甚至是京东零售体系外的，同时通天塔技术和产品也在积极主动寻求变化和创新，这些因素结合在一起驱动通天塔孵化出了一个以技术为导向的项目：通天塔积木，旨在构建一个基于完全开放的前端 SDK 和后端数据源&服务、高度灵活和强大的积木画布、能够快速移植和部署到任何第三方 IT 环境的活动搭建解决方案，这套方案的初衷和设计理念也契合了京东国际化赋能和 PaaS 化的战略。
过去几年通天塔一直处于快速的业务能力建设和架构完善的阶段，以应对不断增长的业务需求和容量、高可用等技术需求，现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力，主流程的新需求越来越少，个性化需求和非标准化流程的数据源和服务接入的需求越来越多，有些甚至是京东零售体系外的，同时通天塔技术和产品也在积极主动寻求变化和创新，这些因素结合在一起驱动通天塔孵化出了一个以技术为导向的项目：通天塔积木，旨在构建一个基于完全开放的前端SDK和后端数据源&服务、高度灵活和强大的积木画布、能够快速移植和部署到任何第三方IT环境的活动搭建解决方案，这套方案的初衷和设计理念也契合了京东国际化赋能和PaaS化的战略。目前通天塔积木已经取得阶段性成果，已开始赋能京东国内和国际站，但如何应对异常复杂的积木业务逻辑和不可预知的业务变化，构建业务和底层技术基础实施的完全解耦的系统，一直是我们面对的巨大挑战。也是时候从更高视角来看清问题和源头，思考一种能应对和控制业务复杂度、具备强扩展性和弹性的解决方案。纵观我们的目标，DDD这个词不知不觉映入了我的眼帘。
在开发简单的业务逻辑时，可编写面向过程的代码，使用事务脚本模式，即一组类实现行为，另一组类负责存储状态。事务脚本通常是没有状态的类，它访问没有行为的数据类以完成持久化任务。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
