本文是我学习课程《软件设计之美》的学习总结第五部分，记录对于DDD领域驱动设计方法的整体理解。
这里记录的是学习分享内容，文章维护在 Github：studeyang/leanrning-share。
领域驱动设计学习拦路虎之一就是众多的概念，第一次接触这些概念会有一定的理解成本，不过正是这些概念支撑起的领域驱动设计，接下来会以电商为例对其中的核心概念做介绍。
本文作者：bryanzhao，微信支付后台开发工程师 | 导语 随着业务的不断发展，我们发现自己的系统开始变得有点臃肿，为了减少复杂性，我们尝试借助DDD来改善我们的系统。本文记录了自己对DDD的理解和实践过程，欢迎大家一起探讨。见识所限，难免有理解不到位，希望路过的大佬不吝赐教。 一、为什么需要DDD 当朋友和你聊工作时，你能否一语中的，说清你在开发中的业务内容及其价值？ 当产品和你聊需求时，你是否遇到过反复沟通之后才发现讲的不是同个东西的情况？ 当你在做需求评估时，你是否经常发现一个小的需求改动，总
2.实现方式：DDD 分层架构、整洁架构、CQRS 和六边形架构等 （我们采用DDD 分层架构）
参考DDD的设计，DDD官方的架构草图，总体架构分为四层，Infrastructure(基础实施层)，Domain(领域层)，Application(应用层)，Interfaces(表示层，也叫用户界面层或是接口层)。
期待已久的【领域驱动设计实战工作坊——金融科技专场】终于在上周末落下了帷幕。一起来瞧瞧过去的这两天，我们完成了怎样的一次头脑风暴和思想碰撞！
目前团队大多数项目都是基于DDD分层架构开发的，而不是传统的MVC模式，这就让很多之前没有接触过DDD思想的同学在刚开始接触项目的时候有点懵。那么什么DDD？这种DDD项目结构和之前的有哪些不同，我该如何开发我的代码，开发不同职责的代码该放在哪里？下面就我的理解，说一说DDD的分层架构。
本文参考了我的同事肖然、王威和刘尚奇于2017年7月22日在ThoughtWorks北京办公室所讲授的“领域驱动的微服务架构设计——实战工作坊”的课程内容，同时参考了我的同事亢江妹在业务分析工作中所使用的“拆分API故事”的实践方法，在此表示感谢。
软件设计首要面对的挑战是如何应对复杂多变的业务问题。而对于业务中台来说，这个问题变得尤为突出。一方面，数字化时代，高度不确定并且快速变化的商业环境必然要求企业的业务也能够及时快速的响应，业务复杂度随之也越来越高；另一方面，业务中台作为企业级能力承载与共享的中台，它是要把大部分业务能力积累沉淀为上层应用能够共享复用的能力池。如何识别与隔离业务中的变与不变，保持复杂度总体可控，并使业务中台架构如实地与业务保持演进，是业务中台构建的关键。
领域驱动设计中定义了超多的概念，如果不多找几篇资料综合的去看，正确的理解比较困难，下面搜集整理了大部分的领域驱动中的概念，并加以理解描述。
领域驱动设计（Domain Driven Design，DDD）是由Eric Evans最早提出的综合软件系统分析和设计的面向对象建模方法，如今已经发展为一种针对大型复杂系统的领域建模与分析方法。它完全改变了传统软件开发工程师针对数据库进行的建模方法，从而将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为，通过合理运用面向对象的封装、继承、多态等设计要素，降低或隐藏整个系统的业务复杂性，并使得系统具有更好的扩展性，应对纷繁多变的现实业务问题。
聚合分组法采用“相关性”来划分限界上下文，其问题在于缺少一个主题，而子域恰好可以用来提供这个主题。本文的“愿景”-“核心域”-“周边子域”方法，不是唯一分解问题域的方法，任何可以将领域分解成高内聚低耦合的子域的方法都是可行的方法。
DDD 是什么，DDD 的英文全称是 Domain-Driven Design，翻译过来就是领域驱动设计。
微服务构建本质上是软件构建过程中长期演进积累的一系列理念、架构原则、工具和最佳实践。
记得很多年以前读Evans的《领域驱动设计 – 软件复杂性核心应对之道》，那个时候DDD还很少人知道，更不用说实践了，这本书呢也在我的书柜里沉睡了很多年。而最近发现，不光传统重业务的软件公司，就连很多互联网公司也在推DDD。
最先介绍领域驱动设计（domain-driven design）的是在程序员 Eric Evans 2004年出版的《领域驱动设计:复杂软件核心复杂应对之道》书籍中，领域驱动设计是领域概念的扩展和应用，并且将它应用在软件开发中。它的目标是将软件相关部分连接到不断发展的模型中，以此更容易创建复杂的应用。
随着软件系统越来越庞大，需求越来越模糊，代码越来越混乱，测试越来越困难，技术演进基本不可能，而其中大型复杂的软件项目更容易走向系统老化的过程，形成需求难、开发难、测试难、创新难，单体架构局部业务膨胀可以拆成微服务，那么微服务局部业务膨胀又应该怎么做？DDD之所以火，即能解决微服务解决不了的问题。DDD是为了解决快速变化、复杂系统的设计问题。
多数有经验的程序开发者都应该听说过DDD，并且尝试过将其应用在自己的项目中。不知你是否遇到过这样的场景：你创建了一个资源库（Repository），但一段时间之后发现这个资源库和传统的DAO越来越像了，你开始反思自己的实现方式是正确的吗？或者，你创建了一个聚合，然后发现这个聚合是如此的庞大，它为什么引用了如此多的对象，难道又是我做错了吗？
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
从遇到问题开始 当人们要做一个软件系统时，一般总是因为遇到了什么问题，然后希望通过一个软件系统来解决。 比如，我是一家企业，然后我觉得我现在线下销售自己的产品还不够，我希望能够在线上也能销售自己的产品。所以，自然而然就想到要做一个普通电商系统，用于实现在线销售自己企业产品的目的。 再比如，我是一家互联网公司，公司有很多系统对外提供服务，面向很多客户端设备。但是最近由于各种原因，导致服务经常出故障。所以，我们希望通过各种措施提高服务的质量和稳定性。其中的一个措施就是希望能做一个灰度发布的平台，这个平台可以提供
限界上下文是语义和语境上的边界。这意味着边界内的每个代表软件模型的组件都有着特定的含义并处理特定的事务。限界上下文中的这些组件有特定的上下文语境和语义理据。 当限界上下文被当作组织的关键战略举措进行开发时，即被称之为核心域。
尽管微服务中的“微”一词表示服务的规模，但它并不是使用微服务的唯一标准。当团队转向基于微服务的架构时，他们旨在提高敏捷性以及自主且频繁地部署功能。很难确定这种架构风格的简单定义。我喜欢Adrian Cockcroft的关于微服务的简短定义：“ 面向服务的体系结构，它由松散耦合的、具有上下文边界的元素组成。”
Redux 的创建者 Dan Abramov 说他不知道什么是领域驱动设计。尽管如此，令人印象深刻的是 Redux 与 DDD 的相似之处。在本文中，我解释了 DDD 是什么，一些关键概念，以及 Redux 如何实现其思想。理解两者，我们可以提供更好的实现；来自不同世界的两种方法相互碰撞并利用相同的设计原则。
微服务构建本质上是软件构建过程中长期演进积累的一系列理念、架构原则、工具和最佳实践。 领域驱动设计的软件思想体系和方法论可以用于指导微服务建模、微服务划分、微服务架构设计等相关工作，它可以促使技术人员与领域专家达成共识，构建领域边界合理、具备明确界限上下文、关注点分离、独立自治的微服务。 1领域驱动设计概述 领域驱动设计（Domain Driven Design）概念的兴起可以追溯到 1986 年，《人月神话》的作者 Brooks 提出软件的本质复杂性（Essential Complexity）存在于复杂的
模型是用来解决特定的问题，一般我们只讲“模型对于这个领域是否更有用”，而不是那个模型更好。
我本身就是一个不太会拒绝的人，这点和雷军相似。最近一周，有网友说要给我投稿，内容见本文。所以，本文是转载的一篇文章，有喜欢的可以深入学习！
通过前面的文章介绍，相信大家对于什么是 DDD 有了初步的了解，知道它是一种微服务的架构设计方法论，为我们解决如何建立领域模型，如何实现微服务划分等提供了方向和指导。但是对于如何具体落地使用 DDD，可能大家还是一脸懵 B 的状态，因此从本文开始以及后面的文章将对如何进行 DDD 落地进行详细的阐述。在这其中还是会涉及到 DDD 中的一些重要概念，原本想着在一篇文章中介绍所有的概念，但是我觉得，概念总是在它该出现的时候出现才会让大家印象深刻，否则这些概念只是死板的概念，我们不清楚他为什么出现以及可以解决什么问题。
本文将讨论微服务与 DDD 涉及到的概念、策划和设计方法，并且尝试将一个单体应用拆分成多个基于 DDD 的微服务。
点击上方蓝色字体，选择“设为星标” 回复”学习资料“获取学习宝典 文章来源：https://www.jdon.com/59597 目录 简介 什么是DDD 如何在实践中应用DDD 问题空间 解决方案空间 从领域模型到微服务 结论 在Airwallex，领域驱动设计（DDD）方法被用来指导如何对复杂的业务问题和系统设计进行建模。 在这篇博客中，我们试图全面介绍用DDD模式对支付系统进行建模的做法。 | 简介 支付系统是一个相当复杂和多变的系统，从订单、欺诈、通知、与各种支付方式的整合到资金清算和结
微服务中的术语"微"传达了一个服务的大小，但这不是将一个应用变为微服务的唯一准则。当团队转变到基于微服务的架构时，需要提高敏捷性(自动部署和频繁发布)。很难对微服务架构的风格做一个准确的定义。我倾向于Adrian Cockcroft 的定义："由松耦合且具有边界上下文的元素构成的面向服务的架构"。
京东作为中国最大的自营式B2C电商平台，提供一站式综合性购物，服务亿万家庭，涵盖3C、家电、消费品、服饰、家居家装、生鲜和新通路（B2B），满足了消费者的多元化需求。每天都会发布相关的促销活动，来勾起消费者的购物欲望；每逢佳节还会进行大量的让利惠民，来促进全民狂欢。
过去几年，通天塔一直处于快速的业务能力建设和架构完善的阶段，以应对不断增长的业务需求和容量、高可用等技术需求，现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力，主流程的新需求越来越少，个性化需求和非标准化流程的数据源和服务接入的需求越来越多，有些甚至是京东零售体系外的，同时通天塔技术和产品也在积极主动寻求变化和创新，这些因素结合在一起驱动通天塔孵化出了一个以技术为导向的项目：通天塔积木，旨在构建一个基于完全开放的前端 SDK 和后端数据源&服务、高度灵活和强大的积木画布、能够快速移植和部署到任何第三方 IT 环境的活动搭建解决方案，这套方案的初衷和设计理念也契合了京东国际化赋能和 PaaS 化的战略。
过去几年，通天塔一直处于快速的业务能力建设和架构完善的阶段，以应对不断增长的业务需求和容量、高可用等技术需求，现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力，主流程的新需求越来越少，个性化需求和非标准化流程的数据源和服务接入的需求越来越多，有些甚至是京东零售体系外的，同时通天塔技术和产品也在积极主动寻求变化和创新，这些因素结合在一起驱动通天塔孵化出了一个以技术为导向的项目：通天塔积木，旨在构建一个基于完全开放的前端
今天的企业应用程序无疑是复杂的，并依赖一些专门技术（持久性，AJAX，Web服务等）来完成它们的工作。作为开发人员，我们倾向于关注这些技术细节是可以理解的。但事实是，一个不能解决业务需求的系统对任何人都没有用，无论它看起来多么漂亮或者如何很好地构建其基础设施。
过去几年通天塔一直处于快速的业务能力建设和架构完善的阶段，以应对不断增长的业务需求和容量、高可用等技术需求，现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力，主流程的新需求越来越少，个性化需求和非标准化流程的数据源和服务接入的需求越来越多，有些甚至是京东零售体系外的，同时通天塔技术和产品也在积极主动寻求变化和创新，这些因素结合在一起驱动通天塔孵化出了一个以技术为导向的项目：通天塔积木，旨在构建一个基于完全开放的前端SDK和后端数据源&服务、高度灵活和强大的积木画布、能够快速移植和部署到任何第三方IT环境的活动搭建解决方案，这套方案的初衷和设计理念也契合了京东国际化赋能和PaaS化的战略。目前通天塔积木已经取得阶段性成果，已开始赋能京东国内和国际站，但如何应对异常复杂的积木业务逻辑和不可预知的业务变化，构建业务和底层技术基础实施的完全解耦的系统，一直是我们面对的巨大挑战。也是时候从更高视角来看清问题和源头，思考一种能应对和控制业务复杂度、具备强扩展性和弹性的解决方案。纵观我们的目标，DDD这个词不知不觉映入了我的眼帘。
当我们只关心一个模型元素的属性时，或者说对于同一类模型实例我们不用区别每一个时，只关心其属性时，这些对象就可以归为值对象。
DDD全写 domain driver design ，也称为领域驱动设计。大型复杂业务系统架构一般都会用到，在提高系统扩展性有很大帮助。
内容摘要：以数字化驱动的业务转型战略为中心，制定组件化业务能力规划，以此建立敏捷/轻量的业务架构；在业务架构内将业务组件映射为子域，在子域内通过DDD设计应用架构，同时进一步修正业务架构。
在低代码平台中，如果需要支持复杂模型多数情况下会要求具备模块级别的源码导出功能，独立模块可以导出为独立运行的原生代码方便与业系统进一步集成。在低代码平台相对成熟的今天，这一功能也成为了绝大多数商业企业级低代码平台的必备功能，本文将从模块代码导出的角度来聊一下，低代码平台的代码出码设计。
我认为，要想应用 DDD，首要任务就是要吃透 DDD 的核心设计思想，搞清楚 DDD、微服务和中台之间的关系。中台本质是业务模型，微服务是业务模型的系统落地，DDD 是一种设计思想，它可以同时指导中台业务建模和微服务设计，它们之间就是这样的一个铁三角关系。DDD 强调领域模型和微服务设计的一体性，先有领域模型然后才有微服务，而不是脱离领域模型来谈微服务设计。
你的源代码是不是感觉像一个大泥球？依赖项是否在您的代码库中交织在一起，以至于改变感觉很危险或不可能？ 随着业务的增长和领域模型（您在应用程序中解决的业务问题）变得更加复杂，我们如何在不从头开始重新编写所有内容的情况下解开我们创建的混乱？更好的是，我们如何避免一开始就陷入混乱？ 鸟瞰图 以下是 Python 架构模式中介绍的技术的简要总结： 分层架构 单一职责 视图 vs 服务 vs 存储库 vs ORM vs 域 依赖倒置 高级与低级模块 抽象 领域驱动设计 先说“业务上下文” 领域建模（事件风暴等
1. 什么是领域（Domain） 我们所做的软件系统的目的都是来解决一系列问题，例如做一个电商系统来在线销售自己企业的产品；做一个灰度发布平台来提升服务的质量和稳定性。任何一个系统都会属于某个特定的领域，例如： 论坛是一个领域：要做一个论坛，那这个论坛的核心业务是确定的：比如用户发帖、回帖等核心基本功能； 电商系统是一个领域：只要是电商领域的系统，那核心业务就是：商品浏览、购物车、下单、减库存、付款交易等核心环节； 同一个领域的系统都具有相同的核心业务，因为他们要解决的问题的本质是类似的。因此可以推断：一个
在学习 DDD领域驱动设计 的过程中，这种方法包括特别的抽象概念，晦涩难懂，本文结合作者理解，对其方法论中的一些概念进行解析。
把问题空间分割为规模更小且易于处理的若干子问题。分割后的问题需要足够小，以便一个人单枪匹马就能够解决他们；其次，必须考虑如何将分割后的各个部分装配为整体。分割得越合理越易于理解，在装配成整体时，所需跟踪的细节也就越少。即更容易设计各部分的协作方式。评判什么是分治得好，即高内聚低耦合。以火车为例，每个车厢都要符合承重要求，行李车厢承重能力要高于其他车厢，车厢间的连接要牢固且易于拆解，有足够的灵活性方便转弯。另外大件行李应该单独存放，避免占用普通车厢的空间，餐车应该在整个列车的中间，方便用餐
你是否还在为微服务应该拆多小而争论不休？到底如何才能设计出收放自如的微服务？怎样才能保证业务领域模型与代码模型的一致性？或许本文能帮你找到答案。 本文是基于 DDD 的微服务设计和开发实战篇，通过借鉴领域驱动设计思想，指导微服务项目团队进行设计和开发（理论篇详见《当中台遇上 DDD，我们该如何设计微服务？》）。本文包括三部分内容：第一部分讲述领域驱动设计基本知识，包括：分层架构、服务视图、数据视图和领域事件发布和订阅等；第二部分讲述微服务设计方法、过程、模板、代码目录、设计原则等内容；最后部分以一个项目为例讲述基于 DDD 的微服务设计过程。
架构设计是基于架构原则和目标给出问题解决方案的过程。架构和设计遵循相同的原则和方法，只是解决问题的规模和层次不同，而这规模和层次没有明显界限。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
