haoxin963的专栏

基于DDD领域模型并支持SaaS平台的企业级开发脚手架.开源地址：https://gitee.com/xtoon/xtoon-boot官网：http://xtoon-boot.xiangtoon.com在线演示：http://xtoon-boot.demo.xiangtoon.com如果有什么问题或建议可以加群（QQ：130950009），交流技术，分享经验。为何选择xtoon-boot解决编写过程式和事务代码，造成后期维护逻辑混乱、维护成本高的痛点； 抛弃MVC框架，拥抱更.

将实体和值对象划分为聚合并围绕着聚合定义边界。选择一个实体作为每个聚合的根，并仅允许外部对象持有对聚合根的引用。作为一个整体来定义聚合的属性和不变量，并把其执行责任赋予聚合根或指定的框架机制。

通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体 。应该尽量使用值对象建模而非实体对象。即便一个领域概念必须建模成实体，在设计时也应更偏向于将其作为值对象容器，而非子实体容器。因为可以非常容易对值对象进行创建、测试、使用、优化和维护。

实体（Entity，又称为Reference Object）很多对象不是通过他们的属性定义的，而是通过一连串的连续事件和标识定义的。主要由标识定义的对象被称为ENTITY。

战术设计的产出可以是用 UML 表达的类图，需要细化到具体的属性，同时确保在代码级别可实现。它是战术设计中最重要和最复杂的模式之一，聚合基于另外两个战术标准，即实体和值对象。区分值对象与实体的区别在于，值对象是不可变的，并且没有唯一标识，仅由其属性的值定义。在整个领域模型中， 实体有自己独立的生命周期，这样可以让我们方便地获取到实体整个生命周期的变迁历史。工厂的出现，隔离了对象的创建过程。使用模块后， 可以有效地帮咱隔离关注点， 对应着Java中的包或C#中的命名空间，也总是遵循着统一语言。

在使用REST时，客户端的领域服务将访问远程的开放主机服务，远程服务器以发布语言的形式返回，下游的防腐层将返回内容翻译成本地上下文的领域对象。对于下游客户来说，你需要根据自己的领域模型创建一个单独的层，该层作为上游系统的委派向你的系统提供功能。对于一些特殊的需求，你可以采用一次性的翻译予以处理，这样可以保持协议的简单性和连贯性。上下文映射图表现的是项目当前的状态，如果项目会在将来发生变化，你可以到那时才对上下文映射图做相应的更新。因此，在上游团队的计划中，我们应该顾及到下游团队的需求。

这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。

你可以认为子域代表的是一个单一的、有逻辑的领域模型。通常，大多数的业务领域都过于庞大和复杂，难以作为整体来分析，因此我们一般只关心那些必须在单个项目中涉及的子域。子域可以用来逻辑地拆分整个业务领域，这样你才能理解存在于大型复杂项目中的。

那么，面对一个特定的业务领域，他们必然要首先统一对所面对的领域的认识，同时，在沟通的过程中他们要采用互相能够听懂的术语，只有这样才能高效沟通，最终形成无限接近于问题领域的实际可用的软件产品。我们在前面已经讨论过，软件设计整个过程都是知识的加工过程，不仅在需求分析时存在密集的业务领域知识，开发人员在做程序设计甚至编写代码是也可能产生新的知识，只有在业务专家和开发人员的沟通过程中，坚持使用通用语言进行沟通，才能高效地彼此分享知识，保持同步。如前面所说，业务模型是浓缩的、结构化的真实业务领域的反映。

事件风暴通过工作坊的形式，由PM、RD、业务各方共同参与的， 发现并对齐领域知识。比较传统的做法是找一面大的白版，使用各种颜色的便签纸填写相关内容，往白板上粘贴。现在也有一些更便捷的支持协作的在线工具可供使用：BeeArt。

我认为，UML图、代码与文档仅仅是表达领域模型的一种载体而已，如果绘制出来的UML图或者编写的代码与文档并没有传递领域知识，那就不是领域模型。既然如此，不管领域模型的表现形式，只要它正确地传递了领域知识，并有助于业务人员与技术人员的交流，就可以说是领域模型。要建立正确的领域模型并不简单，需要领域专家、设计、开发人员积极沟通共同努力，然后才能使大家对领域的认识不断深入，从而不断细化和完善领域模型；领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；它的建立是一个迭代的演进的过程。

通过业务场景，对用户故事以及用例的分析，梳理限界上下文，确定领域边界以及上下文映射图(Context Map)，建立领域模型，分析领域事件，聚合、实体、以及值对象。为了降低业务理解复杂度，DDD 通常将领域划分为子域，通过分而治之的方法分析问题。就可在统一的领域边界内用统一的语言进行交流。通过对业务的拆解以及公司团队的业务定位，将业务场景分解，识别出核心领域、通用域、支撑域。通用语言（Ubiquitous language）是指在软件设计中，业务人员和开发人员需要使用无歧义的统一语言来对话。

建立模型的可行方案：1、与领域专业人员沟通，可通过边提问边回答的方式。2，挖掘领域中的名词和流程。3、尝试画图，通过图来走查各种场景。4、相互学习，共同消除了术语上的 不一致和歧义，并对模型进行精化，最终画出类图。5、简单实现核心的领域模型，屏蔽无关基础设施和界面，进行单元测试和验证需求。有效建模的要素：1、模型和实现的绑定。最初的原型虽然简陋，但它在模型与实现之间建立了早期链接，而 且在所有后续的迭代中我们一直在维护该链接。2、建立了一种基于模型的语言。3、开发..

模型的定义模型是对特定问题或领域的关键信息的抽象，这样使我们更专注问题；模型的作用1、模型和实现相互影响，我们通过模型分析来最终实现产品，实现也是对模型的解释；2、模型为团队沟通提供通用的语言；3、模型是对领域知识的浓缩；软件的核心软件是为用户解决领域相关的问题，领域中的复杂性是我们关注的重点；...

在传统的瀑布方法中，业务专家与分析员进行讨论，分析员消化理解这些知识后，对其进行抽象并将结果传递给程序员，再由程序员编写软件代码。由于这种方法完全没有反馈，因此总是失败。分析员全权负责创建模型，但他们创建的模型只是基于业务专家的意见。他们既没有向程序员学习的机会，也得不到早期软件版本的经验。知识只是朝一个方向流动，而且不会累积。有些项目使用了迭代过程，但由于没有对知识进行抽象而无法建立起知识体系。开发人员听专家们描述某项所需的特性，然后开始构建它。他们将结果展示给专家，并询问接下来做什么。 如果程序员愿

如何学习DDD，虽然DDD早在2004年就提出了，但一直没有火起来。直到最近两年才慢慢被大家熟知。深究其原因，我觉得有以下几个原因

业务复杂且需要长期维护的时候需要DDD

当朋友和你聊项目时，你能否一语中的，说清你在开发中的业务内容及其价值？当产品和你聊需求时，是否遇到过反复沟通之后才发现讲的不是同个东西的情况？当你在做需求评估时，是否经常发现一个小的需求改动，总是牵一发动全身？当你看产品文档时，是否经常发现代码很多逻辑文档里没更新进去？当你接手前任的项目，是否要花很大的精力去熟悉散乱的代码，经历修改他人代码的痛苦？当项目维护周期很长时，是否发现维护成本越来越高，经常想推倒重来？

领域驱动设计（英语：domain-driven design，缩写 DDD），是 Eric Evans 于 2004 年提出的一种软件设计方法和理念。

XP概述XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。在以前的开发过程中，很多规则已经难于遵循，很多流程复杂而难于理解，很多项目中文档的制作过程正在失去控制。人们试图提出更全面更好的一揽子方案，或者寄希望于更复杂的、功能更强大的辅助开发工具（CaseTools），但总是不能成功，而且开发规范和流程变得越来越复杂和难以实施。XP就是在这样的情况下诞生的，它是灵巧的轻量级软件开发方法，它跳出复杂的流程和文档，而是以轻量的框架和极限的思想为核心进行开发。这里讲的极限编