笔者在《React语境下前端DDD的思考》一文中提出了在前端考虑引入DDD的想法【未经授权禁止转载】转载请注明出处：www.tangshuang.net，在过去的一年多，这篇文章获得了非常大的【作者：唐霜】【访问 www.tangshuang.net 获取更多精彩内容】关注，被反复转载，收到的评论和探讨也非常【访问 www.tangshuang.net 获取更多精彩内容】原创内容，盗版必究。多。在这一年多的时间，我在项目中努力践行未经授权，禁止复制转载。【版权所有，侵权必究】这一想法，并随着时间的推移，以及在业务开未经授权，禁止复制转载。原创内容，盗版必究。发中遇到各种特殊的需求场景，做了非常多的转载请注明出处：www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】尝试，也沉淀了很多思想。这篇文章，将把我本文作者：唐霜，转载请注明出处。【原创不易，请尊重版权】所想到的一些东西写下来，一方面可以帮助读【访问 www.tangshuang.net 获取更多精彩内容】【转载请注明来源】者认识DDD，另一方面希望通过我的项目中原创内容，盗版必究。【本文受版权保护】的实战了解如何基于DDD去设计自己的项目本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net。

【原创不易，请尊重版权】本文作者：唐霜，转载请注明出处。【本文首发于唐霜的博客】

本文的所有内容我梳理为一张思维导图，你可【访问 www.tangshuang.net 获取更多精彩内容】著作权归作者所有，禁止商业用途转载。以根据这张图，获得大致的内容框架。

【作者：唐霜】著作权归作者所有，禁止商业用途转载。

另外，在开始之前，我需要说明的是，基于D【原创不易，请尊重版权】【作者：唐霜】DD并不是万能的，不同的业务领域其能否真转载请注明出处：www.tangshuang.net【版权所有，侵权必究】正起到提升效率的作用，在不同的设计中，D【作者：唐霜】【本文受版权保护】DD能否收回最大的回报，是不确定的，不能本文版权归作者所有，未经授权不得转载。本文作者：唐霜，转载请注明出处。因为DDD在这两年的重新热门，就强行采取未经授权，禁止复制转载。【版权所有，侵权必究】这一设计，读者应该结合自己的项目特征，适未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。当的选择符合自己项目的设计。

DDD知识体系

DDD是Domain-Driven De【转载请注明来源】【原创不易，请尊重版权】sign的缩写，其中的Domain旨在强本文作者：唐霜，转载请注明出处。本文版权归作者所有，未经授权不得转载。调“系统设计以业务为核心”，简单讲，DD【未经授权禁止转载】【访问 www.tangshuang.net 获取更多精彩内容】D就是“从业务出发的系统设计方法”，它的【本文首发于唐霜的博客】本文版权归作者所有，未经授权不得转载。对立面是“从纯技术出发对系统进行设计”。著作权归作者所有，禁止商业用途转载。本文版权归作者所有，未经授权不得转载。本节不详细阐述每一个概念，而是提纲挈领式著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。的梳理如果想要了解DDD，应该知道的那些【转载请注明来源】转载请注明出处：www.tangshuang.net点，具体的每个知识点，需要读者自己深入学转载请注明出处：www.tangshuang.net【版权所有，侵权必究】习。

DDD的意义

DDD的核心在于定义业务边界和控制变化，未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。按照它的设计方法设计出来的系统，应该具备本文作者：唐霜，转载请注明出处。【关注微信公众号：wwwtangshuangnet】演进式架构以支持增量式开发，基于这一理念【作者：唐霜】【关注微信公众号：wwwtangshuangnet】，可以确保我们的一套业务系统在持续迭代几【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。年甚至上十年后，仍然还能在它的上面持续更著作权归作者所有，禁止商业用途转载。转载请注明出处：www.tangshuang.net新功能。

著作权归作者所有，禁止商业用途转载。本文作者：唐霜，转载请注明出处。【本文受版权保护】【本文首发于唐霜的博客】

这对于已经在一套业务系统中工作了三、四年【原创内容，转载请注明出处】【原创内容，转载请注明出处】，正要准备重构的团队，非常有吸引力。这样【版权所有，侵权必究】【原创内容，转载请注明出处】的项目团队，一定是在业务上积累了很多逻辑【原创不易，请尊重版权】未经授权，禁止复制转载。，但在面临新的变更时，要么改动会牵一发动【本文受版权保护】著作权归作者所有，禁止商业用途转载。全身带来问题，要么是难以新增新的业务进去【作者：唐霜】原创内容，盗版必究。，以至于在进一步开发时举步维艰。笔者经历【关注微信公众号：wwwtangshuangnet】本文版权归作者所有，未经授权不得转载。过这样的痛苦，总结而言，原有项目代码的问【关注微信公众号：wwwtangshuangnet】【原创内容，转载请注明出处】题在于：1. 要实现某一业务逻辑的代码分【转载请注明来源】本文作者：唐霜，转载请注明出处。散；2. 代码依赖无顺序可言，改动牵连出转载请注明出处：www.tangshuang.net未经授权，禁止复制转载。更多问题；3. 看上去可以复用，但是真正本文作者：唐霜，转载请注明出处。【访问 www.tangshuang.net 获取更多精彩内容】拿出来时发现还不如copy一份再改改。而【关注微信公众号：wwwtangshuangnet】【版权所有，侵权必究】基于DDD的理念进行重构后，能消除80%【版权所有，侵权必究】【访问 www.tangshuang.net 获取更多精彩内容】以上的类似问题，如果设计合理，还能提供更【原创内容，转载请注明出处】【关注微信公众号：wwwtangshuangnet】多的可扩展能力。

【原创不易，请尊重版权】本文作者：唐霜，转载请注明出处。

DDD不是什么？

我们看到很多介绍DDD的文章，一开始很容【原创内容，转载请注明出处】【作者：唐霜】易把它误认为是类似MVC或其他什么形式的转载请注明出处：www.tangshuang.net【转载请注明来源】架构模式。实际上，DDD只提供方法论，而【未经授权禁止转载】本文作者：唐霜，转载请注明出处。且是只提供设计方法，它不解决技术问题，而【原创不易，请尊重版权】本文版权归作者所有，未经授权不得转载。是只提供设计思路，你可以把它理解为思想层【版权所有】唐霜 www.tangshuang.net本文版权归作者所有，未经授权不得转载。面的武器。

原创内容，盗版必究。【转载请注明来源】【转载请注明来源】【原创不易，请尊重版权】

当然，DDD并不完全脱离技术。它要求工程【未经授权禁止转载】本文作者：唐霜，转载请注明出处。师们能够有效的和完全不懂技术的业务人员进原创内容，盗版必究。【本文受版权保护】行沟通，在了解具体业务设计、逻辑、过程、本文作者：唐霜，转载请注明出处。【原创不易，请尊重版权】概念时，没有认知上的壁垒。从这个角度讲，著作权归作者所有，禁止商业用途转载。【访问 www.tangshuang.net 获取更多精彩内容】DDD是写给技术人员的业务术语词汇表创建【版权所有】唐霜 www.tangshuang.net本文作者：唐霜，转载请注明出处。方法论，是让技术人员有机会用抽象的概念对【版权所有】唐霜 www.tangshuang.net【关注微信公众号：wwwtangshuangnet】业务进行技术表达，最后再将这些表达，落实原创内容，盗版必究。【版权所有】唐霜 www.tangshuang.net到技术上，变为代码，构建我们的系统。

【原创内容，转载请注明出处】【本文首发于唐霜的博客】

我个人把DDD分为两个部分：沟通方法论和【转载请注明来源】未经授权，禁止复制转载。技术方法论。其中沟通方法论就是如上文所述【版权所有，侵权必究】【版权所有，侵权必究】的，让技术人员完全融入业务领域的方法论。著作权归作者所有，禁止商业用途转载。【版权所有，侵权必究】技术方法论则是在获得业务认知之后，将抽象著作权归作者所有，禁止商业用途转载。原创内容，盗版必究。的业务概念，落实为可行的技术的方法论。如本文作者：唐霜，转载请注明出处。【本文首发于唐霜的博客】果我们能够完全理解业务，但是我们却需要去本文作者：唐霜，转载请注明出处。【转载请注明来源】争论实现这一业务需要如何做技术实现，那么【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。说明我们没有利用DDD的方法论，因为从D【作者：唐霜】【转载请注明来源】DD的目标而言，就是要让我们技术人员，在【版权所有，侵权必究】【版权所有】唐霜 www.tangshuang.net了解完业务之后，可以按照它提供的方法，快本文作者：唐霜，转载请注明出处。本文作者：唐霜，转载请注明出处。速落实为技术层面的东西。如果团队中的大部未经授权，禁止复制转载。原创内容，盗版必究。分成员都拥护这一方法论，那么当其中一人把【访问 www.tangshuang.net 获取更多精彩内容】【作者：唐霜】业务落实为技术时，其他人不会有任何异议，【本文首发于唐霜的博客】【访问 www.tangshuang.net 获取更多精彩内容】因为他们也是这么想的。

掌握DDD并不能解决我们怎么把这个组件写本文作者：唐霜，转载请注明出处。【关注微信公众号：wwwtangshuangnet】的非常灵活，也不能解决我们怎么让应用跑起转载请注明出处：www.tangshuang.net原创内容，盗版必究。来性能更好，更不能解决我们如何收集应用错【本文首发于唐霜的博客】【本文受版权保护】误日志的问题。它甚至在我们代码层面不会有原创内容，盗版必究。【关注微信公众号：wwwtangshuangnet】任何的呈现，它只呈现在我们团队成员的脑海【本文受版权保护】【转载请注明来源】中。

【本文首发于唐霜的博客】本文作者：唐霜，转载请注明出处。本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。

但是，作为思想武器，它让我们技术人员从业【版权所有】唐霜 www.tangshuang.net【本文受版权保护】务的角度而非技术的角度去设计系统，我不能本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。说这是一种进步或更高明的系统设计方式，但【本文首发于唐霜的博客】本文版权归作者所有，未经授权不得转载。是随着我们不断实践DDD，我们会发现以往【作者：唐霜】本文作者：唐霜，转载请注明出处。很多看上去混乱的东西，慢慢变得有迹可循。

著作权归作者所有，禁止商业用途转载。【原创内容，转载请注明出处】

DDD中的基本概念

统一语言

当技术人员和业务人员在进行沟通时，双方的本文作者：唐霜，转载请注明出处。【转载请注明来源】术语常常会带来误解，统一业务术语在系统中【作者：唐霜】【版权所有】唐霜 www.tangshuang.net的命名，将使得每一次沟通更加有效。业务人【未经授权禁止转载】原创内容，盗版必究。员或者系统的产品设计人员往往对技术细节不原创内容，盗版必究。【关注微信公众号：wwwtangshuangnet】了解，在沟通过程中，他们往往会忽略某些细【原创不易，请尊重版权】【本文受版权保护】节，他们会觉得“我表达的你应该懂，你脑海【本文首发于唐霜的博客】【访问 www.tangshuang.net 获取更多精彩内容】里看到的应该和我脑海里看到的一样”，而这【原创不易，请尊重版权】【原创内容，转载请注明出处】些细节常常会影响到后续的技术实现，对于业【作者：唐霜】【访问 www.tangshuang.net 获取更多精彩内容】务团队而言，我们应该寻求统一语言，让业务【转载请注明来源】【原创内容，转载请注明出处】人员或产品人员能够在设计过程中，逐渐培养【转载请注明来源】【本文首发于唐霜的博客】技术实现的思维，提供可能影响技术实现的更【转载请注明来源】著作权归作者所有，禁止商业用途转载。多细节，避免到了后面才突然讲“哎呀，这里【关注微信公众号：wwwtangshuangnet】【本文首发于唐霜的博客】怎么是这样，我说的是xxx这样，你怎么做转载请注明出处：www.tangshuang.net【作者：唐霜】成了xxx这样”。构建团队内的概念词典，本文版权归作者所有，未经授权不得转载。【原创不易，请尊重版权】沉淀业务构思图，虽然可能在前期会花掉很多【版权所有】唐霜 www.tangshuang.net【原创内容，转载请注明出处】时间，但是对于确保业务的准确实现是有帮助【原创不易，请尊重版权】【版权所有】唐霜 www.tangshuang.net的。

【转载请注明来源】原创内容，盗版必究。

在一个团队内，我们应该保证统一的认知，当【原创不易，请尊重版权】【作者：唐霜】我们提到某一个业务的实现时，我们应该确保【访问 www.tangshuang.net 获取更多精彩内容】【原创内容，转载请注明出处】我所讲的某一个概念，和你认知的这个概念是原创内容，盗版必究。【版权所有】唐霜 www.tangshuang.net一样的，而不能出现理解上的分歧。例如，“本文作者：唐霜，转载请注明出处。本文作者：唐霜，转载请注明出处。我们要在流程中实现按角色权限审批的控制能【本文首发于唐霜的博客】【原创内容，转载请注明出处】力”，这里有非常复杂的上下文，例如“流程本文作者：唐霜，转载请注明出处。【未经授权禁止转载】”“角色权限”“控制”，如果没有统一语言【未经授权禁止转载】本文作者：唐霜，转载请注明出处。，那么对这些词语的理解是不同的，在技术实本文版权归作者所有，未经授权不得转载。【原创内容，转载请注明出处】现时也就可能存在偏差，只有团队成员都能理著作权归作者所有，禁止商业用途转载。本文作者：唐霜，转载请注明出处。解这里的“流程”是指“这一业务需要进行审【访问 www.tangshuang.net 获取更多精彩内容】转载请注明出处：www.tangshuang.net批和推进，存在多个阶段，每个阶段我们都有未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。固定的称谓，阶段存在流转，流转有很多条件转载请注明出处：www.tangshuang.net本文作者：唐霜，转载请注明出处。……”这一极为复杂的业务上下文时，才能在未经授权，禁止复制转载。本文作者：唐霜，转载请注明出处。技术实现时，把这一需求定位到“业务流”这【版权所有】唐霜 www.tangshuang.net【本文受版权保护】一模块上。复杂的业务上下文对于新成员而言本文作者：唐霜，转载请注明出处。【关注微信公众号：wwwtangshuangnet】，需要有一个学习的时间，而如果有统一语言原创内容，盗版必究。【版权所有，侵权必究】的沉淀，则可以帮助这些新成员快速了解。

在我们进行业务沟通时，我们可以借助UML本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。作为工具，因为它可以用图的形式表达出来，【未经授权禁止转载】本文版权归作者所有，未经授权不得转载。同时，对于技术人员，后续可以直接利用UM【关注微信公众号：wwwtangshuangnet】原创内容，盗版必究。L来进行建模参考。UML是Unified【转载请注明来源】【转载请注明来源】 Modeling Language的缩【本文首发于唐霜的博客】未经授权，禁止复制转载。写，普遍用于建模，对业务进行说明、可视化【本文首发于唐霜的博客】【转载请注明来源】和文档编制。不过UML也有局限，它更倾向【原创内容，转载请注明出处】【版权所有】唐霜 www.tangshuang.net于面向对象编程，技术属性很强，对于非技术著作权归作者所有，禁止商业用途转载。本文作者：唐霜，转载请注明出处。人员而言门槛还是会比较高。或许excel【原创内容，转载请注明出处】【原创不易，请尊重版权】和思维导图这些看上去与技术无关，甚至有点【本文受版权保护】【版权所有】唐霜 www.tangshuang.netlow的工具，可能却是更好的工具。

【作者：唐霜】【转载请注明来源】【未经授权禁止转载】

领域模型

首先一定要强调，“领域模型”不是代码！不本文作者：唐霜，转载请注明出处。本文作者：唐霜，转载请注明出处。需要说三遍！在代码中被称为领域模型的部分【本文受版权保护】本文作者：唐霜，转载请注明出处。，仅仅是构成领域模型的其中一部分。领域模【原创不易，请尊重版权】本文作者：唐霜，转载请注明出处。型是用于描述业务中各类概念的统一语言和技【版权所有】唐霜 www.tangshuang.net转载请注明出处：www.tangshuang.net术实现的总和。简单讲，领域模型用于描述我本文作者：唐霜，转载请注明出处。著作权归作者所有，禁止商业用途转载。们的业务中存在的事物、行为、关联，将这些【本文首发于唐霜的博客】本文版权归作者所有，未经授权不得转载。内容全部组合在一起，就可以在我们眼前呈现【版权所有】唐霜 www.tangshuang.net【转载请注明来源】出我们的系统所要实现的业务的全貌。

【未经授权禁止转载】本文作者：唐霜，转载请注明出处。【转载请注明来源】

领域的规模

【未经授权禁止转载】未经授权，禁止复制转载。【作者：唐霜】【本文首发于唐霜的博客】

一个系统中，一个领域可以分为多个子域，子【转载请注明来源】【本文首发于唐霜的博客】域还能分为多个子域。

领域的分类

一个业务系统中，其实涉及了多个方面，根据原创内容，盗版必究。转载请注明出处：www.tangshuang.net它们与我们所实现的业务的相关程度，可以分转载请注明出处：www.tangshuang.net【原创不易，请尊重版权】为核心域、支撑域、通用域。通常它们是针对【版权所有，侵权必究】【关注微信公众号：wwwtangshuangnet】子域而言的，也就是对子域的一个分类。核心【访问 www.tangshuang.net 获取更多精彩内容】【关注微信公众号：wwwtangshuangnet】域即系统所关联业务的核心部分，例如一个支转载请注明出处：www.tangshuang.net本文版权归作者所有，未经授权不得转载。付系统的核心部分就是支付；支撑域是围绕核【作者：唐霜】本文版权归作者所有，未经授权不得转载。心业务的其他附属业务部分，例如支付系统中【版权所有】唐霜 www.tangshuang.net【原创内容，转载请注明出处】的订单，虽然订单本质上和支付无关，支付只【关注微信公众号：wwwtangshuangnet】未经授权，禁止复制转载。需要支付方+接收方+中介，但是订单是该支未经授权，禁止复制转载。未经授权，禁止复制转载。付关联的业务；通用域是可能与业务无强相关著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。单需要作为系统的一部分，例如系统中的登录【作者：唐霜】【本文首发于唐霜的博客】、用户、权限等等，这些领域在行业有通用解【未经授权禁止转载】本文版权归作者所有，未经授权不得转载。决方案，同时在本系统中可能存在某些特殊性原创内容，盗版必究。未经授权，禁止复制转载。，但是它们与我们的核心业务相隔甚远，但又【本文首发于唐霜的博客】【本文受版权保护】必须存在。

限界上下文

【转载请注明来源】本文版权归作者所有，未经授权不得转载。未经授权，禁止复制转载。

如何确定一个领域呢？领域的边界通过限界上未经授权，禁止复制转载。【原创不易，请尊重版权】下文（Bound Context）来定义【本文首发于唐霜的博客】著作权归作者所有，禁止商业用途转载。。在该上下文以内的就是该领域的东西，以外本文作者：唐霜，转载请注明出处。【版权所有，侵权必究】的则本领域管不着，也不想管。限界上下文束未经授权，禁止复制转载。原创内容，盗版必究。缚了该领域的边界，从而确定了技术上这部分原创内容，盗版必究。【关注微信公众号：wwwtangshuangnet】的内容，只能在该范围内被使用，而不应该跨【访问 www.tangshuang.net 获取更多精彩内容】【访问 www.tangshuang.net 获取更多精彩内容】领域使用。

【转载请注明来源】本文版权归作者所有，未经授权不得转载。原创内容，盗版必究。

在DDD中，界限上下文面临三个问题：如何本文作者：唐霜，转载请注明出处。【本文受版权保护】划分？怎么映射？怎样防腐？

本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshua转载请注明出处：www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】ng.net转载请注明出处：www.tangshua【关注微信公众号：wwwtangshuangnet】本文版权归作者所有，未经授权不得转载。ng.net【作者：唐霜】

限界上下文划分是首要要做的，但是也是最难【本文受版权保护】【本文首发于唐霜的博客】的。从我们所有人的经验来看，几乎没有一个未经授权，禁止复制转载。本文版权归作者所有，未经授权不得转载。人可以一次性准确划分系统中的全部限界上下未经授权，禁止复制转载。【版权所有】唐霜 www.tangshuang.net文。我们经常会在实施过程中，发现之前的划【原创不易，请尊重版权】【版权所有，侵权必究】分不合理，一旦出现这种情况，往往意味着我【本文受版权保护】【本文首发于唐霜的博客】们需要花很大的力气对这个部分进行重构，但本文版权归作者所有，未经授权不得转载。【版权所有，侵权必究】是你很难避免。总体上有三个划分原则：概念相同，含义不同应该分到不同转载请注明出处：www.tangshuang.net转载请注明出处：www.tangshuang.net上下文；把与外部系统打交道的那部分拆分出【原创不易，请尊重版权】本文作者：唐霜，转载请注明出处。去；两个团队不要在一个限界上下文里面。

【原创内容，转载请注明出处】【未经授权禁止转载】

限界上下文的映射，就是将被划分好的不同限【本文受版权保护】【原创内容，转载请注明出处】界上下文之间的关联标注出来，同时还要标注【作者：唐霜】著作权归作者所有，禁止商业用途转载。出它们之间的依赖关系。有了映射，我们就可本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。以纵览我们系统中各个子域之间关系的全貌。

本文作者：唐霜，转载请注明出处。著作权归作者所有，禁止商业用途转载。【原创内容，转载请注明出处】本文作者：唐霜，转载请注明出处。

U到D是影响作用方向，D到U是依赖方向

【作者：唐霜】【未经授权禁止转载】【原创内容，转载请注明出处】【本文受版权保护】

限界上下文防腐是指在确定映射之后，通过技未经授权，禁止复制转载。【本文受版权保护】术手段在限界上下文之间设置防腐层，避免由转载请注明出处：www.tangshuang.net著作权归作者所有，禁止商业用途转载。于它们之间的依赖关系，导致过度的耦合。防本文版权归作者所有，未经授权不得转载。原创内容，盗版必究。腐层作为这种依赖关系的接管者，当依赖关系【作者：唐霜】【原创内容，转载请注明出处】发生变更时，可以在防腐层中做文章，以避免【本文首发于唐霜的博客】【版权所有，侵权必究】限界上下文受依赖过度影响而需要全部重构。

建模方案

DDD通过建模来让领域中的事物、行为、关原创内容，盗版必究。本文作者：唐霜，转载请注明出处。联确定下来，使之固定化，可以作为代码在系原创内容，盗版必究。【作者：唐霜】统中被使用。它提供了如下几种建模方案：实【本文受版权保护】本文版权归作者所有，未经授权不得转载。体、值对象、聚合和聚合根、服务、工厂、仓本文版权归作者所有，未经授权不得转载。【原创不易，请尊重版权】库（资源库）。这部分内容其实与后端结合比著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。较紧密，前端开发人员往往无法理解。而且D【原创不易，请尊重版权】【原创不易，请尊重版权】DD的方法是面向对象的建模方法，这与前端【作者：唐霜】【版权所有，侵权必究】盛行的函数式编程志道不同，但我个人而言，【原创内容，转载请注明出处】【原创不易，请尊重版权】这些方法为我们提供了非常实在的全套理论，【原创内容，转载请注明出处】【未经授权禁止转载】是比较有效的方法。

在其他文章中，这部分将会被重点展开，但在未经授权，禁止复制转载。【原创内容，转载请注明出处】本文中，这部分内容显然更为基础，因此并不【关注微信公众号：wwwtangshuangnet】未经授权，禁止复制转载。过多展开。在未来的开发过程中，你会反复的【访问 www.tangshuang.net 获取更多精彩内容】【版权所有，侵权必究】用到这些方法。你还要去思考，在什么场景下【原创内容，转载请注明出处】【访问 www.tangshuang.net 获取更多精彩内容】，采用哪一种建模方案，避免使用错误的方案本文版权归作者所有，未经授权不得转载。原创内容，盗版必究。，导致后续的开发降低效率。

【原创不易，请尊重版权】本文版权归作者所有，未经授权不得转载。

领域事件

【本文首发于唐霜的博客】原创内容，盗版必究。【作者：唐霜】未经授权，禁止复制转载。

和普通技术层面的事件相比，领域事件更多具【访问 www.tangshuang.net 获取更多精彩内容】【版权所有，侵权必究】备了业务属性。一方面，在业务上，它可以抽本文版权归作者所有，未经授权不得转载。未经授权，禁止复制转载。象某些特定场景，在这些场景下，存在特定的【本文受版权保护】【原创内容，转载请注明出处】逻辑；另一方面，在技术上，它可以实现解耦著作权归作者所有，禁止商业用途转载。【作者：唐霜】，把原本需要跨领域调用的耦合代码，进行拆原创内容，盗版必究。原创内容，盗版必究。分，从而避免代码上的过度耦合。

事件往往与行为放在一起，但这里的行为并非本文作者：唐霜，转载请注明出处。本文版权归作者所有，未经授权不得转载。“用户的操作”，而是“业务状态的变更”。未经授权，禁止复制转载。【未经授权禁止转载】在领域中，“当……时，需要……”这样的情本文作者：唐霜，转载请注明出处。本文版权归作者所有，未经授权不得转载。况，“当……时”即一个事件。但在构建领域【版权所有，侵权必究】本文版权归作者所有，未经授权不得转载。模型时，我们并非需要把所有的领域事件都列著作权归作者所有，禁止商业用途转载。本文作者：唐霜，转载请注明出处。举出来，我们常常只需要关注那些比较特殊的【本文首发于唐霜的博客】【原创内容，转载请注明出处】事件，即那种可能存在跨子域操作的事件。例【未经授权禁止转载】【本文受版权保护】如，“当支付完成时，订单进入配送阶段”，未经授权，禁止复制转载。【转载请注明来源】其中“当支付完成”这个事件往往发生在支付【原创不易，请尊重版权】【本文首发于唐霜的博客】领域，而“订单进入配送阶段”则是对订单领未经授权，禁止复制转载。【原创不易，请尊重版权】域的操作，如果强行在支付领域中调用订单领著作权归作者所有，禁止商业用途转载。【原创不易，请尊重版权】域的方法，则可能导致订单领域不得不考虑提【版权所有】唐霜 www.tangshuang.net本文版权归作者所有，未经授权不得转载。供对外的接口。而如果我们基于事件的订阅与【转载请注明来源】原创内容，盗版必究。发布来实现这个过程，那么支付领域只管发布【版权所有】唐霜 www.tangshuang.net本文作者：唐霜，转载请注明出处。该事件，订单领域可以订阅该事件，甚至其他原创内容，盗版必究。【本文受版权保护】领域也可能订阅该事件。如此一来，就可以让【作者：唐霜】本文作者：唐霜，转载请注明出处。一个逻辑可以很好的解耦的同时，又能顺利走本文版权归作者所有，未经授权不得转载。【未经授权禁止转载】通。

【转载请注明来源】【关注微信公众号：wwwtangshua【原创内容，转载请注明出处】【未经授权禁止转载】ngnet】著作权归作者所有，禁止商业用途转载。

转载请注明出处：www.tangshua【原创内容，转载请注明出处】【本文首发于唐霜的博客】ng.net【作者：唐霜】【未经授权禁止转载】

然而，对于前端开发有一定经验的同学而言，【版权所有】唐霜 www.tangshuang.net【版权所有，侵权必究】其实对订阅发布并不喜欢，与我个人而言甚至【访问 www.tangshuang.net 获取更多精彩内容】【作者：唐霜】有点抵触，我会尝试对订阅发布进行更高一级【作者：唐霜】【未经授权禁止转载】的封装。之所以出现这种情况，是因为基于事【版权所有】唐霜 www.tangshuang.net【本文首发于唐霜的博客】件中心的逻辑流程实际上代码会比较割裂，单未经授权，禁止复制转载。转载请注明出处：www.tangshuang.net纯从代码上看，我们不知道这个事件是在哪里转载请注明出处：www.tangshuang.net【版权所有】唐霜 www.tangshuang.net被触发的，或者我们不知道这个事件有没有正【未经授权禁止转载】【访问 www.tangshuang.net 获取更多精彩内容】确被订阅。因此，在实际工作中，我们需要在【访问 www.tangshuang.net 获取更多精彩内容】【访问 www.tangshuang.net 获取更多精彩内容】领域建模时，勾勒出领域事件的全貌，画出领【未经授权禁止转载】【访问 www.tangshuang.net 获取更多精彩内容】域事件地图，从而让我们有机会去检查，我们本文版权归作者所有，未经授权不得转载。本文版权归作者所有，未经授权不得转载。在业务上的需求，是被代码正确实现了的。

【原创内容，转载请注明出处】原创内容，盗版必究。

架构设计

DDD作为技术方法论，在架构设计上提供了【版权所有】唐霜 www.tangshuang.net【转载请注明来源】自己的观点。应用构建过程中，我们首先是以【作者：唐霜】【本文受版权保护】领域为中心，围绕领域去构建应用的。但同时原创内容，盗版必究。【版权所有】唐霜 www.tangshuang.net我们要考虑在实际实现过程中，技术上往往会【本文首发于唐霜的博客】【原创不易，请尊重版权】有一些局限，因此，我们不可能以完全理想化【原创不易，请尊重版权】转载请注明出处：www.tangshuang.net的方式构建我们的应用，因此，DDD并不提【版权所有】唐霜 www.tangshuang.net著作权归作者所有，禁止商业用途转载。供具体的架构方案，而是提供设计思路。

【原创内容，转载请注明出处】未经授权，禁止复制转载。

四层架构

著作权归作者所有，禁止商业用途转载。【转载请注明来源】

将我们的整个应用自底向顶分为“基础设施层【关注微信公众号：wwwtangshuangnet】本文版权归作者所有，未经授权不得转载。->领域层->应用层->【版权所有】唐霜 www.tangshuang.net未经授权，禁止复制转载。;用户界面层”，由于DDD的首创主要是面【原创内容，转载请注明出处】原创内容，盗版必究。向后端，因此其中的“应用层”更多的是站在【版权所有】唐霜 www.tangshuang.net【未经授权禁止转载】后端的角度去看待后端应用的实现，更多强调【本文首发于唐霜的博客】原创内容，盗版必究。数据的存取和数据流，中间还要考虑后端软硬【作者：唐霜】转载请注明出处：www.tangshuang.net环境和各类服务的协调。而在前端，则可能不【作者：唐霜】【转载请注明来源】同，我们可能更多会去看某一业务的具体实现【原创不易，请尊重版权】本文版权归作者所有，未经授权不得转载。，例如我们知道有支付这个领域对象，但是，本文版权归作者所有，未经授权不得转载。【版权所有，侵权必究】在前端应用中，我们需要为支付的创建、查看【关注微信公众号：wwwtangshuangnet】【版权所有，侵权必究】、转账等等去进行处理，因此，在领域层和用【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。户界面层之间，存在着一种将这些逻辑聚合在【转载请注明来源】原创内容，盗版必究。一起的部分。

“洋葱架构”

【作者：唐霜】【访问 www.tangshuang.n【原创不易，请尊重版权】本文版权归作者所有，未经授权不得转载。et 获取更多精彩内容】著作权归作者所有，禁止商业用途转载。本文作者：唐霜，转载请注明出处。

又名整洁架构。洋葱架构的取名源于这种架构【关注微信公众号：wwwtangshuangnet】【关注微信公众号：wwwtangshuangnet】设计为层层依赖的形式，它的核心要点在于依未经授权，禁止复制转载。【原创不易，请尊重版权】赖方向，外层只能对其内层产生依赖，这也就【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。意味着内存不能反向依赖外层或跨层依赖。这著作权归作者所有，禁止商业用途转载。著作权归作者所有，禁止商业用途转载。以架构的设计，使得应用在代码层面具有非常【版权所有】唐霜 www.tangshuang.net【版权所有】唐霜 www.tangshuang.net强的约束性，虽然有的时候并不方便，但与我本文作者：唐霜，转载请注明出处。【版权所有】唐霜 www.tangshuang.net们创建增量式的持续维护的应用的目标而言，未经授权，禁止复制转载。本文版权归作者所有，未经授权不得转载。是非常有益的。

本文作者：唐霜，转载请注明出处。【未经授权禁止转载】著作权归作者所有，禁止商业用途转载。【原创不易，请尊重版权】

【未经授权禁止转载】【转载请注明来源】

六边形架构

【访问 www.tangshuang.n未经授权，禁止复制转载。本文作者：唐霜，转载请注明出处。et 获取更多精彩内容】【关注微信公众号：wwwtangshua未经授权，禁止复制转载。【本文受版权保护】ngnet】原创内容，盗版必究。

也被称为端口与适配器架构，这种架构在洋葱【原创不易，请尊重版权】原创内容，盗版必究。架构基础上，增加了端口和适配器，每一条边本文作者：唐霜，转载请注明出处。【作者：唐霜】代表不同类型的短裤，端口要么处理输入，要原创内容，盗版必究。【版权所有】唐霜 www.tangshuang.net么处理输出，每种外界类型，都有一个适配器原创内容，盗版必究。【原创内容，转载请注明出处】与之匹配，外界通过接口与内部交互。

【关注微信公众号：wwwtangshua【访问 www.tangshuang.net 获取更多精彩内容】未经授权，禁止复制转载。ngnet】未经授权，禁止复制转载。

未经授权，禁止复制转载。转载请注明出处：www.tangshua著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。ng.net【本文受版权保护】

虽然三种架构形式上不同，但是它们的本质相未经授权，禁止复制转载。【转载请注明来源】差无几，即都是以领域模型为中心，构建业务【本文首发于唐霜的博客】【本文首发于唐霜的博客】的核心逻辑。

【原创不易，请尊重版权】【本文首发于唐霜的博客】

战略设计和战术设计

简单讲，所谓战略设计和战术设计，就是设计著作权归作者所有，禁止商业用途转载。【作者：唐霜】做事的方法、步骤、技巧。战略设计从宏观角本文版权归作者所有，未经授权不得转载。本文作者：唐霜，转载请注明出处。度，挖掘产品价值，建立统一语言，进行限界【本文受版权保护】原创内容，盗版必究。上下文划分，建立领域模型，但没有具体的实本文作者：唐霜，转载请注明出处。【未经授权禁止转载】施。通过战略设计，让团队可以吃透整个业务著作权归作者所有，禁止商业用途转载。【关注微信公众号：wwwtangshuangnet】，从宏观层面把我整套系统要做那些事，价值【关注微信公众号：wwwtangshuangnet】原创内容，盗版必究。在哪里，哪些是重点，应该按照怎样的步骤和【访问 www.tangshuang.net 获取更多精彩内容】【转载请注明来源】节奏进行接下来的工作，有哪些需要其他解决本文版权归作者所有，未经授权不得转载。本文版权归作者所有，未经授权不得转载。的问题。而战术设计则是具体实现某个目标的原创内容，盗版必究。【作者：唐霜】方法，通过事件风暴、用例分析、四色建模、未经授权，禁止复制转载。转载请注明出处：www.tangshuang.net领域故事讲述等等，其中前文讲的建模方案、【版权所有】唐霜 www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】架构设计也包含在内。

【未经授权禁止转载】【本文受版权保护】

后端DDD概览

后端DDD，本质是在微服务架构基础上，借【未经授权禁止转载】【原创内容，转载请注明出处】鉴DDD限界上下文的识别方案，更合理的拆本文作者：唐霜，转载请注明出处。【本文受版权保护】分微服务，避免不必要的服务拆分，构筑更符原创内容，盗版必究。本文作者：唐霜，转载请注明出处。合业务需求的微服务体系。基于微服务，我们未经授权，禁止复制转载。未经授权，禁止复制转载。可以非常有效的分离限界上下文，将单个上下著作权归作者所有，禁止商业用途转载。【本文受版权保护】文隔离在单个微服务中，在该微服务内实现该【原创不易，请尊重版权】【未经授权禁止转载】限界上下文的业务逻辑。而限界上下文之间的【未经授权禁止转载】本文版权归作者所有，未经授权不得转载。映射，则是通过微服务之间的调用；领域事件【本文受版权保护】转载请注明出处：www.tangshuang.net则是通过通用的消息通知服务，等等。基于如【版权所有，侵权必究】原创内容，盗版必究。此去构建我们的后端应用，则可以按照DDD【原创内容，转载请注明出处】转载请注明出处：www.tangshuang.net的理念，从业务出发，用微服务架构的技术去【作者：唐霜】著作权归作者所有，禁止商业用途转载。实现领域驱动的设计。但是DDD主要在思考【版权所有，侵权必究】【转载请注明来源】业务划分，而微服务还要考虑物理层面的边界本文版权归作者所有，未经授权不得转载。【原创不易，请尊重版权】，还要考虑性能、可用性、安全性等等，因此原创内容，盗版必究。【本文首发于唐霜的博客】，DDD更多是提供一种指导思想。

【本文受版权保护】【关注微信公众号：wwwtangshua【原创内容，转载请注明出处】【未经授权禁止转载】ngnet】未经授权，禁止复制转载。

然而，分散的看，我们很难定义哪些代码是D【关注微信公众号：wwwtangshuangnet】原创内容，盗版必究。DD哪些是微服务架构，但整体的看，它们是【未经授权禁止转载】著作权归作者所有，禁止商业用途转载。为整个系统服务的，无论是在架构设计过程中【本文受版权保护】【本文首发于唐霜的博客】，还是在设计模式选择过程中，抑或代码模型【转载请注明来源】【版权所有，侵权必究】的设计中，我们总会有多个选择，每一个选择转载请注明出处：www.tangshuang.net【关注微信公众号：wwwtangshuangnet】看上去都可能是对的，只是在这其中，我们以【版权所有】唐霜 www.tangshuang.net原创内容，盗版必究。DDD为指导思想，选择了符合复杂业务处理【作者：唐霜】【版权所有】唐霜 www.tangshuang.net的那一种。

【本文首发于唐霜的博客】转载请注明出处：www.tangshua转载请注明出处：www.tangshuang.net著作权归作者所有，禁止商业用途转载。ng.net本文版权归作者所有，未经授权不得转载。

前端DDD详解

在前端去引入DDD并不能让前端的开发变得【版权所有】唐霜 www.tangshuang.net转载请注明出处：www.tangshuang.net简单，DDD并不解决技术问题，我们之所以【作者：唐霜】转载请注明出处：www.tangshuang.net引入DDD，主要是解决复杂业务环境下前端【版权所有，侵权必究】转载请注明出处：www.tangshuang.net编程令人混乱的代码设计，而非让前端写代码【作者：唐霜】未经授权，禁止复制转载。更简单更舒服。前端代码之所以在业务实现过著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。程中显得混乱，是因为我们大部分应用是围绕【版权所有】唐霜 www.tangshuang.net本文版权归作者所有，未经授权不得转载。UI为中心进行构建的，这也就意味着业务是未经授权，禁止复制转载。【未经授权禁止转载】为UI服务的，业务的数据是为了UI的呈现本文作者：唐霜，转载请注明出处。【转载请注明来源】，业务的逻辑是为了交互的判断，因此，为了【未经授权禁止转载】未经授权，禁止复制转载。完成一个UI需求，会牵扯到多个业务或把一【未经授权禁止转载】本文版权归作者所有，未经授权不得转载。个业务的逻辑分散在组件的不同地方，但在完【版权所有】唐霜 www.tangshuang.net【作者：唐霜】成编写之后，后续的需求往往是在业务的基础【未经授权禁止转载】【原创不易，请尊重版权】上进行调整，此时再去改业务逻辑，就极其吃【转载请注明来源】【原创不易，请尊重版权】力。这种开发时围绕UI，后续维护和迭代却【原创不易，请尊重版权】【转载请注明来源】围绕业务的割裂，是造成前端代码难以持续增未经授权，禁止复制转载。【关注微信公众号：wwwtangshuangnet】量式演进的主要原因。

前端DDD与后端的不同

在这个场景下，前端和后端的最大不同在于，本文作者：唐霜，转载请注明出处。【关注微信公众号：wwwtangshuangnet】前端没有后端需要的数据库、服务、系统环境著作权归作者所有，禁止商业用途转载。【原创不易，请尊重版权】、网络协议等等，但比后端多出界面和交互部本文版权归作者所有，未经授权不得转载。原创内容，盗版必究。分。因此，前后端的架构设计在遵循DDD理未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。念时，实际是有出入的，不能用后端的设计思原创内容，盗版必究。未经授权，禁止复制转载。维去对照前端。下文我们将专注分解前端DD【原创不易，请尊重版权】【作者：唐霜】D的实现，若有与后端不一致时，应该将上述【关注微信公众号：wwwtangshuangnet】【本文首发于唐霜的博客】区别考虑进去后再来思考。

【作者：唐霜】【原创不易，请尊重版权】转载请注明出处：www.tangshua本文作者：唐霜，转载请注明出处。【原创内容，转载请注明出处】ng.net

项目工程变更

要再前端实施DDD，我们的前端项目工程将【本文首发于唐霜的博客】本文版权归作者所有，未经授权不得转载。会发生一定的变化，传统的单体式应用结构已【本文首发于唐霜的博客】【版权所有】唐霜 www.tangshuang.net经无法满足分领域设计的应用需求，所以，我【版权所有】唐霜 www.tangshuang.net转载请注明出处：www.tangshuang.net们的项目团队可能需要经历一场痛苦的项目重著作权归作者所有，禁止商业用途转载。【作者：唐霜】建过程。

【未经授权禁止转载】原创内容，盗版必究。未经授权，禁止复制转载。本文版权归作者所有，未经授权不得转载。

基于微前端的业务模块拆分

就像后端进行微服务拆分一样，在前端应用中本文版权归作者所有，未经授权不得转载。未经授权，禁止复制转载。，我们将业务进行拆分，从底到顶的去把一个本文作者：唐霜，转载请注明出处。原创内容，盗版必究。业务模块构建出来。底，就是领域模型，顶就【作者：唐霜】【原创不易，请尊重版权】是该业务模块所呈现出来的界面，中间需要控未经授权，禁止复制转载。本文版权归作者所有，未经授权不得转载。制层作为连接，使整个业务模块呈现出较为独原创内容，盗版必究。【作者：唐霜】立的，能在自己的限界上下文完成自己业务全【本文首发于唐霜的博客】【原创不易，请尊重版权】部的模块。基于微前端的理念，我们可以构建转载请注明出处：www.tangshuang.net【原创内容，转载请注明出处】出呈现单一业务的子应用，该子应用内部可以本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。完成业务逻辑、界面呈现、交互过程的全部，著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。同时，基于防腐层或端口抑或领域事件，在子【未经授权禁止转载】【原创不易，请尊重版权】应用之间所带来的副作用影响到其他子应用中著作权归作者所有，禁止商业用途转载。本文作者：唐霜，转载请注明出处。。在这个过程中，我个人的经验里，有一个非【版权所有】唐霜 www.tangshuang.net未经授权，禁止复制转载。常重要的点，就是路由。对于单一业务模块而【作者：唐霜】【未经授权禁止转载】言，往往不止一个页面，需要通过路由进行展本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net现的控制。我在Nautil中设计了分布式的路由，可以让独立的子应用【版权所有】唐霜 www.tangshuang.net【原创内容，转载请注明出处】拥有自己的路由，而放到整个应用中时，不影【原创不易，请尊重版权】【原创内容，转载请注明出处】响子应用路由的切换。

基于构建工具链的聚合应用和多端分发

在有业务模块子应用的基础上，我们需要对它【本文首发于唐霜的博客】【版权所有，侵权必究】们进行聚合，创建应用的门户，作为用户真正本文版权归作者所有，未经授权不得转载。未经授权，禁止复制转载。访问的站点/入口。不过，聚合应用并不是简著作权归作者所有，禁止商业用途转载。本文作者：唐霜，转载请注明出处。单的将子应用组合在一起，在聚合应用中，我【原创内容，转载请注明出处】【原创内容，转载请注明出处】们需要处理子应用之间的通信、跳转、同步更【版权所有】唐霜 www.tangshuang.net【关注微信公众号：wwwtangshuangnet】新等问题，我们需要给门户添加导航菜单以及【原创内容，转载请注明出处】本文版权归作者所有，未经授权不得转载。整个门户的整体界面框架。由于这种特性，我【未经授权禁止转载】【本文首发于唐霜的博客】们可以做到利用相关的子应用聚合为多个门户【原创不易，请尊重版权】著作权归作者所有，禁止商业用途转载。，例如商家有自己的门户、消费者有自己的门【原创内容，转载请注明出处】【关注微信公众号：wwwtangshuangnet】户、物流、供应链……在这一整套系统中，不【作者：唐霜】【版权所有，侵权必究】同的人有自己的门户去管理自己的内容，但实转载请注明出处：www.tangshuang.net未经授权，禁止复制转载。际上，它们底下，是聚合了对应业务的相同模【版权所有】唐霜 www.tangshuang.net未经授权，禁止复制转载。块，再底层则是相同的领域模型。

本文版权归作者所有，未经授权不得转载。原创内容，盗版必究。

在此基础上，同一个门户还可能需要分发到不著作权归作者所有，禁止商业用途转载。【原创内容，转载请注明出处】同的端，PC端、APP、小程序等等。我们转载请注明出处：www.tangshuang.net【转载请注明来源】前端有丰富的生态，可以做到一套代码多端运【版权所有】唐霜 www.tangshuang.net【版权所有，侵权必究】行，基于构建工具链，将同一套代码分发到不【本文首发于唐霜的博客】【访问 www.tangshuang.net 获取更多精彩内容】同端上。如果存在交互上的不一致需求，也只未经授权，禁止复制转载。本文作者：唐霜，转载请注明出处。需要在用户界面层做调整，而下面的领域层、原创内容，盗版必究。转载请注明出处：www.tangshuang.net应用层，都可以复用。

未经授权，禁止复制转载。未经授权，禁止复制转载。

团队人员分工与职责变更

单一人员负责在整个应用中这里修修那里补补【原创不易，请尊重版权】【本文首发于唐霜的博客】的分工模式，是没有办法适应DDD的思想的【转载请注明来源】未经授权，禁止复制转载。。在团队中，一定会存在一部分人员更注重业【转载请注明来源】原创内容，盗版必究。务，一部分人更注重技术的分布情况。在DD【版权所有】唐霜 www.tangshuang.net【版权所有】唐霜 www.tangshuang.netD思想下的架构情况下，团队人员的合理设定【本文受版权保护】【关注微信公众号：wwwtangshuangnet】，能够更加有效的发挥这一架构的能力。

按照分层架构设计，我们可以将团队的人员职未经授权，禁止复制转载。【作者：唐霜】责划分为如下：

本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。【未经授权禁止转载】

【原创内容，转载请注明出处】未经授权，禁止复制转载。转载请注明出处：www.tangshua转载请注明出处：www.tangshuang.net【转载请注明来源】ng.net原创内容，盗版必究。

上文已经讲过，这里的应用层里面的“应用”转载请注明出处：www.tangshuang.net本文版权归作者所有，未经授权不得转载。和我们平常所讲的Application不【本文受版权保护】【版权所有】唐霜 www.tangshuang.net是一回事，这里的“应用”是将领域扩展为可【本文首发于唐霜的博客】本文版权归作者所有，未经授权不得转载。完成业务的实现部分。一般而言，我们可以认【原创不易，请尊重版权】本文版权归作者所有，未经授权不得转载。为在应用层，主要完成微前端中的子应用的实【关注微信公众号：wwwtangshuangnet】【版权所有】唐霜 www.tangshuang.net现，一个子应用，实际上需要包含领域模型的著作权归作者所有，禁止商业用途转载。【版权所有】唐霜 www.tangshuang.net应用、业务组件的开发、路由的安排、页面的本文版权归作者所有，未经授权不得转载。【本文首发于唐霜的博客】撰写等等工作。当然，由于业务逻辑大部分被【原创内容，转载请注明出处】【作者：唐霜】沉淀在领域层，虽然业务模块的开发者应该熟【版权所有】唐霜 www.tangshuang.net著作权归作者所有，禁止商业用途转载。悉该业务，但是实际上，他更多的是关心如何【未经授权禁止转载】【本文受版权保护】将这一业务进行呈现，即完成界面和交互。而【关注微信公众号：wwwtangshuangnet】【本文受版权保护】用户界面层则更关心聚合应用，是最后给用户著作权归作者所有，禁止商业用途转载。【关注微信公众号：wwwtangshuangnet】使用的一道门。

【关注微信公众号：wwwtangshua著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。ngnet】本文作者：唐霜，转载请注明出处。【本文受版权保护】

代码模型变更

什么是代码模型？即描述代码的工具。简单讲本文作者：唐霜，转载请注明出处。【本文首发于唐霜的博客】，就是我们用图形、文字等形式，把代码的文【未经授权禁止转载】【转载请注明来源】件目录结构以及代码的上下顺序、联系、规则未经授权，禁止复制转载。【作者：唐霜】表达出来，就像我们一开始划分领域时做的一【版权所有，侵权必究】【关注微信公众号：wwwtangshuangnet】样，去划分代码。在划分代码时，我们可能会本文作者：唐霜，转载请注明出处。本文版权归作者所有，未经授权不得转载。调整原本项目的代码，以符合DDD理念，更【关注微信公众号：wwwtangshuangnet】原创内容，盗版必究。好的实施对应的方案。

领域层代码

我们需要抽象出只负责业务部分的领域层代码【原创内容，转载请注明出处】【原创不易，请尊重版权】，这一层的代码只描述业务，不考虑界面交互【版权所有，侵权必究】【原创不易，请尊重版权】，甚至和真正的应用没有任何联系。这也就意【作者：唐霜】【转载请注明来源】味着这部分代码是完全可复用的，是不需要考【访问 www.tangshuang.net 获取更多精彩内容】【原创不易，请尊重版权】虑平台、端的，无论是在PC上还是APP上未经授权，禁止复制转载。【版权所有，侵权必究】，都可以被使用，也不考虑你所使用的视图框【本文受版权保护】转载请注明出处：www.tangshuang.net架，无论在react中还是angular【访问 www.tangshuang.net 获取更多精彩内容】【访问 www.tangshuang.net 获取更多精彩内容】中，它都可以被使用。有了这一层，我们所设著作权归作者所有，禁止商业用途转载。【版权所有】唐霜 www.tangshuang.net计的微前端子应用分团队开发才成为可能，不本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。同的团队可以使用不同技术栈去实现自己的业本文版权归作者所有，未经授权不得转载。【访问 www.tangshuang.net 获取更多精彩内容】务，但是底下的领域层代码是不挑框架的，因【版权所有，侵权必究】【转载请注明来源】此，在PC上使用angular，在app原创内容，盗版必究。未经授权，禁止复制转载。使用react native，都是可行的【本文首发于唐霜的博客】【本文首发于唐霜的博客】。而也正因为领域层囊括了所有的业务逻辑，原创内容，盗版必究。【转载请注明来源】所以，对于上层的建设，可以更加关注UI，本文版权归作者所有，未经授权不得转载。【原创不易，请尊重版权】同时确保了业务逻辑的一致性。

未经授权，禁止复制转载。未经授权，禁止复制转载。原创内容，盗版必究。

业务场景逻辑

真实的业务，往往是基于一个场景完成某种操【原创不易，请尊重版权】原创内容，盗版必究。作，例如支付，有发起支付，也有支付后退款【关注微信公众号：wwwtangshuangnet】【本文受版权保护】等，不同的场景背后的领域是相同的，但是由本文作者：唐霜，转载请注明出处。著作权归作者所有，禁止商业用途转载。于场景的不同，会导致某些业务逻辑的不同。原创内容，盗版必究。本文作者：唐霜，转载请注明出处。这就意味着，无论在领域层还是应用层，基于【关注微信公众号：wwwtangshuangnet】本文版权归作者所有，未经授权不得转载。场景的逻辑都是必须设计好的。当然，这意味原创内容，盗版必究。本文作者：唐霜，转载请注明出处。着我们在阅读代码时，可能需要一次性阅读更本文版权归作者所有，未经授权不得转载。未经授权，禁止复制转载。多。

【作者：唐霜】【转载请注明来源】【原创不易，请尊重版权】【原创不易，请尊重版权】

业务功能模块

即等价于微前端子应用，在领域层基础上，结【原创内容，转载请注明出处】【作者：唐霜】合业务场景，构建出某一具体业务的完整界面转载请注明出处：www.tangshuang.net著作权归作者所有，禁止商业用途转载。交互。

扩展能力

在理想化的设计基础上，几乎所有业务团队都【本文受版权保护】【原创不易，请尊重版权】要面临一些特殊能力的支持，例如你需要支持本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net动态加载字段的配置，比如某个字段在场景A转载请注明出处：www.tangshuang.net【作者：唐霜】下要保留小数，而场景B下要去整，再例如多【版权所有】唐霜 www.tangshuang.net本文作者：唐霜，转载请注明出处。语言的支持，再例如要在系统中支持实现文件原创内容，盗版必究。【作者：唐霜】的转化和加密等等。这些能力其实和业务本身【未经授权禁止转载】【本文受版权保护】无关，甚至对于业务而言，是非必需的，但是本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。对于一个应用而言，产品人员希望支持这些功未经授权，禁止复制转载。【作者：唐霜】能，从体验或可控性角度提升应用的能力。

分层架构设计

整个开发团队需要在分层架构上达成共识，从【本文受版权保护】【版权所有，侵权必究】而可以按照一个思路去分布代码，避免不同成原创内容，盗版必究。本文作者：唐霜，转载请注明出处。员在写自己的模块时，不知道该能力其实已经【未经授权禁止转载】【转载请注明来源】有了，然后自己又造一个轮子。在代码上，我转载请注明出处：www.tangshuang.net原创内容，盗版必究。们会尝试将不同层的代码放在不同的目录中，【原创内容，转载请注明出处】转载请注明出处：www.tangshuang.net文件结构的设计符合分层设计的理念，有助于【访问 www.tangshuang.net 获取更多精彩内容】原创内容，盗版必究。团队协助，有利于后期灵活的开发。

著作权归作者所有，禁止商业用途转载。原创内容，盗版必究。

底层框架封装

要让我们能够按照DDD以及微前端的模式进【本文首发于唐霜的博客】未经授权，禁止复制转载。行开发，我们需要在最底层实现一套框架。这原创内容，盗版必究。【本文首发于唐霜的博客】个框架需要拥有特定能力的基类或函数的封装【版权所有】唐霜 www.tangshuang.net转载请注明出处：www.tangshuang.net，例如如何进行实体模型的构建，如何创建服转载请注明出处：www.tangshuang.net著作权归作者所有，禁止商业用途转载。务，如何操作某些对象等等，这些最底层的设本文作者：唐霜，转载请注明出处。【转载请注明来源】计，实际上会形成我们的编程范式；需要建设【原创内容，转载请注明出处】【未经授权禁止转载】适应微前端架构的基础设施，例如顶层应用的【本文受版权保护】【版权所有】唐霜 www.tangshuang.net加载器，分布式的路由，分包的能力，等等；【作者：唐霜】转载请注明出处：www.tangshuang.net需要让代码在灵活性和规范性之间寻找一个平本文版权归作者所有，未经授权不得转载。【未经授权禁止转载】衡，灵活性是开放给开发者更好的接入需要的未经授权，禁止复制转载。未经授权，禁止复制转载。功能，规范性是保障业务运行的准确与稳定。

团队规范

团队内要编制编码规范、强制性写作方式、开本文版权归作者所有，未经授权不得转载。【关注微信公众号：wwwtangshuangnet】发范式，这些东西可以确保团队成员是按照同著作权归作者所有，禁止商业用途转载。【作者：唐霜】一种风格、思路、习惯进行编程，从而降低团转载请注明出处：www.tangshuang.net【原创内容，转载请注明出处】队成员在协作过程中的难度。有的时候，我们本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。会把个人的喜好带入项目，例如我们更喜欢调【本文首发于唐霜的博客】【本文受版权保护】用函数的方式，但团队是通过state来控【原创不易，请尊重版权】本文作者：唐霜，转载请注明出处。制组件，例如我们更喜欢代码直接换行，但是本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。团队要求在每句结束写分号，等等。个人的喜【关注微信公众号：wwwtangshuangnet】本文版权归作者所有，未经授权不得转载。好与团队的规范冲突时，我们要以团队的规范【本文首发于唐霜的博客】本文作者：唐霜，转载请注明出处。为优先，避免在整体代码中，写出突兀的变化著作权归作者所有，禁止商业用途转载。【原创不易，请尊重版权】。

前端DDD的具体实施

在前端构建领域模型，我们需要考虑的东西其【本文首发于唐霜的博客】未经授权，禁止复制转载。实会更多，因为我们不仅要单纯考虑到业务的本文版权归作者所有，未经授权不得转载。原创内容，盗版必究。硬性逻辑，同时也要考虑前端在交互层次上的【转载请注明来源】【本文受版权保护】一些实用性，如果在表达业务上非常优秀，但【本文首发于唐霜的博客】【版权所有，侵权必究】是到了具体开发时很难使用的话，也说明我们【版权所有】唐霜 www.tangshuang.net原创内容，盗版必究。的实践是不足取的。

本文版权归作者所有，未经授权不得转载。本文作者：唐霜，转载请注明出处。【未经授权禁止转载】

领域建模

前端如何进行领域建模呢？我认为需要考虑如【转载请注明来源】著作权归作者所有，禁止商业用途转载。下几个方面。

【未经授权禁止转载】【本文受版权保护】【原创内容，转载请注明出处】本文版权归作者所有，未经授权不得转载。

首先，我们需要划分领域，划分限界上下文，【本文首发于唐霜的博客】【访问 www.tangshuang.net 获取更多精彩内容】从而可以从中提炼出我们建模需要建立哪些实著作权归作者所有，禁止商业用途转载。著作权归作者所有，禁止商业用途转载。体、服务、事件等等。其次，我们要以实体为【作者：唐霜】【原创不易，请尊重版权】核心去逐渐完善我们的领域模型。最后一点，【版权所有】唐霜 www.tangshuang.net原创内容，盗版必究。也是非常重要的一点，我们需要考虑到场景。

【作者：唐霜】原创内容，盗版必究。

实体建模

我们基于 TySheMo 进行实体建模，搭建起我们整个应用的骨架本文作者：唐霜，转载请注明出处。【原创内容，转载请注明出处】。我们已经通过划分，知道我们需要建立哪些本文作者：唐霜，转载请注明出处。【原创不易，请尊重版权】实体。但是实际上，大部分情况下，实体是嵌【转载请注明来源】【作者：唐霜】套的，实体之间存在包含/引用关系。例如我【本文首发于唐霜的博客】【版权所有，侵权必究】们需要建立订单实体，与之关联的还有支付实本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net体、物流实体等等。这些实体，在某些场景下【本文首发于唐霜的博客】未经授权，禁止复制转载。需要关联在一起，有些场景下需要单独拿出来【版权所有】唐霜 www.tangshuang.net转载请注明出处：www.tangshuang.net，在实际场景中，这取决于是否存在某个字段原创内容，盗版必究。著作权归作者所有，禁止商业用途转载。。组成实体的是该实体的字段。和后端不同，本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net我们在前端构建充血模型，单个字段被放在一未经授权，禁止复制转载。原创内容，盗版必究。个 Meta 模型中，该 Meta 作为【未经授权禁止转载】著作权归作者所有，禁止商业用途转载。字段信息交给 Model，Model 作【本文首发于唐霜的博客】【版权所有，侵权必究】为基类，依据 Meta 来生成具体的字段著作权归作者所有，禁止商业用途转载。【原创内容，转载请注明出处】，以及字段之间的约束。例如一个订单：

const PriceMeta = createMeta({
  label: '单价',
  default: null,
})

const CountMeta = createMeta({
  label: '数量',
  default: null,
})

const AmountMeta = createMeta({
  label: '总价',
  default: null,
  compute() {
    const price = this.use(PriceMeta, view => view.value)
    const count = this.use(CountMeta, view => view.value)
    if (count) {
      return price * count
    }
    return null
  },
})

我们创建了三个字段的 Meta，其中 a【转载请注明来源】【关注微信公众号：wwwtangshuangnet】mount 基于另外两个字段自动进行计算著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。。随后，我们创建模型：

class OrderModel extends Model {
  @meta(PriceMeta)
  price: number

  @meta(CountMeta)
  count: number
  
  @meta(AmountMeta)
  amount: number
}

这便是我们订单模型的最基础最原始的形态。著作权归作者所有，禁止商业用途转载。本文版权归作者所有，未经授权不得转载。随后，我们会慢慢去丰富这个模型。例如给单转载请注明出处：www.tangshuang.net【关注微信公众号：wwwtangshuangnet】价和数量增加校验逻辑：

原创内容，盗版必究。【转载请注明来源】

const CountMeta = createMeta({
  label: '数量', 
  default: null,
  required: true,
  min: 0,
  validators: [
    Validator.required('请输入数量'),
    Validator.min('数量必须大于0'),
  ],
})

服务

本文版权归作者所有，未经授权不得转载。本文作者：唐霜，转载请注明出处。本文作者：唐霜，转载请注明出处。本文作者：唐霜，转载请注明出处。

数据服务

转载请注明出处：www.tangshua转载请注明出处：www.tangshuang.net本文版权归作者所有，未经授权不得转载。ng.net转载请注明出处：www.tangshua本文版权归作者所有，未经授权不得转载。本文版权归作者所有，未经授权不得转载。ng.net

对于前端来说，从后端拉取数据是必然的部分【未经授权禁止转载】转载请注明出处：www.tangshuang.net。我们基于 algeb 构建了 DataService，基于这个实现，可以让整个应用的数据更容【版权所有，侵权必究】【转载请注明来源】易管理。同时，这里有一个点，我们可能在M【未经授权禁止转载】著作权归作者所有，禁止商业用途转载。eta中使用DataService，因为【原创内容，转载请注明出处】【原创不易，请尊重版权】我们会将某一个source作为一项配置交【关注微信公众号：wwwtangshuangnet】【原创不易，请尊重版权】给Meta，虽然这在“洋葱模型”中不允许【未经授权禁止转载】【版权所有，侵权必究】，但是实际上，我们可以反过来看数据服务，原创内容，盗版必究。【未经授权禁止转载】它更像是基础设施层的东西，只不过我们利用著作权归作者所有，禁止商业用途转载。【访问 www.tangshuang.net 获取更多精彩内容】了Service的单例模式。

事件服务

【原创不易，请尊重版权】【访问 www.tangshuang.n本文版权归作者所有，未经授权不得转载。【作者：唐霜】et 获取更多精彩内容】

和数据服务一样，我们往往需要在整个模块内本文版权归作者所有，未经授权不得转载。【版权所有，侵权必究】，甚至应用层面，使用事件，事件被具体模块原创内容，盗版必究。未经授权，禁止复制转载。引用，进行订阅或发布，这完全由我们前面提未经授权，禁止复制转载。【版权所有，侵权必究】到的事件图来决定。这里比较麻烦的是事件名本文版权归作者所有，未经授权不得转载。【未经授权禁止转载】的确定，因为如果我们自己确定事件名，会导【版权所有】唐霜 www.tangshuang.net【原创内容，转载请注明出处】致可能两个地方使用了相同事件名而引起冲突【作者：唐霜】【本文首发于唐霜的博客】。解决办法是我们直接在EventServ【版权所有】唐霜 www.tangshuang.net【本文受版权保护】ice上声明事件枚举（enum），在使用【关注微信公众号：wwwtangshuangnet】【转载请注明来源】事件名时，只能使用该枚举内的名称，这可以【本文受版权保护】【本文受版权保护】通过typescript来做好约束。这样【原创不易，请尊重版权】本文版权归作者所有，未经授权不得转载。我们就可以避免在一个EventServi【版权所有，侵权必究】本文版权归作者所有，未经授权不得转载。ce中写出相同的事件名，同时，其他模块使【本文受版权保护】著作权归作者所有，禁止商业用途转载。用了相同事件名，也不会影响本事件服务的执【本文首发于唐霜的博客】未经授权，禁止复制转载。行。

转载请注明出处：www.tangshua原创内容，盗版必究。原创内容，盗版必究。ng.net原创内容，盗版必究。【关注微信公众号：wwwtangshua【本文首发于唐霜的博客】【本文首发于唐霜的博客】ngnet】

业务值对象

本文作者：唐霜，转载请注明出处。著作权归作者所有，禁止商业用途转载。原创内容，盗版必究。

业务工厂

本文作者：唐霜，转载请注明出处。【原创内容，转载请注明出处】转载请注明出处：www.tangshua未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。ng.net【原创内容，转载请注明出处】

我们用函数的形式来向业务提供工厂函数，在未经授权，禁止复制转载。【关注微信公众号：wwwtangshuangnet】工厂函数中，我们往往封装了一些复杂的逻辑未经授权，禁止复制转载。【原创内容，转载请注明出处】，但由于它们其实是代码本身的旁路，因此不转载请注明出处：www.tangshuang.net转载请注明出处：www.tangshuang.net被放在模型和服务中。不过，工厂函数一定是转载请注明出处：www.tangshuang.net【未经授权禁止转载】纯函数，不应该存在副作用，不应该改变入参未经授权，禁止复制转载。本文版权归作者所有，未经授权不得转载。属性或状态。

业务聚合

聚合是一个业务的出口，当然，一个聚合可能转载请注明出处：www.tangshuang.net著作权归作者所有，禁止商业用途转载。被另外一个聚合所聚合，因此，我们讲工厂函本文版权归作者所有，未经授权不得转载。【未经授权禁止转载】数、服务操作聚合、实体，是指同一层面，但本文版权归作者所有，未经授权不得转载。【未经授权禁止转载】实际上在单一聚合内，我们往往把这些工厂、【版权所有】唐霜 www.tangshuang.net本文版权归作者所有，未经授权不得转载。服务、实体全都囊括在内，形成一个业务的闭【原创内容，转载请注明出处】【原创内容，转载请注明出处】环。聚合向外提供接口，用于调用这些封装，【未经授权禁止转载】【未经授权禁止转载】从而实现实体状态的流转。聚合是业务对象、【作者：唐霜】【关注微信公众号：wwwtangshuangnet】业务逻辑的统一出口，也是可以实现跨站跨端【未经授权禁止转载】未经授权，禁止复制转载。复用的关键。在 Nautil 中，聚合用【原创不易，请尊重版权】【原创不易，请尊重版权】 Controller 来表达，一个 C【本文受版权保护】未经授权，禁止复制转载。ontroller 提供了该业务的聚合。

【本文受版权保护】未经授权，禁止复制转载。原创内容，盗版必究。

交互模型

当我们进入具体模块的开发时，我们会发现，【本文受版权保护】未经授权，禁止复制转载。跨端开发中，界面和交互是不一致的，一致的本文作者：唐霜，转载请注明出处。原创内容，盗版必究。是交互逻辑。例如同样是发起支付页面，PC【版权所有，侵权必究】未经授权，禁止复制转载。上和APP上存在巨大的界面差别，虽然界面著作权归作者所有，禁止商业用途转载。【本文首发于唐霜的博客】差别大，但是当点击按钮时，都是要出发调用未经授权，禁止复制转载。本文版权归作者所有，未经授权不得转载。后端的支付接口的逻辑。虽然界面不同，但是本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net交互的逻辑是一样的。抛开界面，对交互逻辑本文版权归作者所有，未经授权不得转载。【作者：唐霜】进行抽象，构建交互模型。例如：

原创内容，盗版必究。【本文首发于唐霜的博客】

abstract class PayView extends View {
  handlePayStart = async () => {
    const { id } = await applyPayment()
    this.onPayStart(id)
  }

  abstract onPayStart(id: string): void
}

我们使用abstract class作为未经授权，禁止复制转载。原创内容，盗版必究。交互模型类，因为我们将在具体实现时直接e【作者：唐霜】【本文首发于唐霜的博客】xtends它。在交互模型中，我们提供回【关注微信公众号：wwwtangshuangnet】【版权所有】唐霜 www.tangshuang.net调函数，组织事件流，载入领域模型，并封装原创内容，盗版必究。【关注微信公众号：wwwtangshuangnet】为具体的方法（大部分会以handle开头本文版权归作者所有，未经授权不得转载。【版权所有】唐霜 www.tangshuang.net），将某些周期方法（大部分以on开头）预著作权归作者所有，禁止商业用途转载。著作权归作者所有，禁止商业用途转载。留出来，等待具体平台上实现。

抽象视图

用于在多端之间，共享统一的视图描述，例如著作权归作者所有，禁止商业用途转载。【转载请注明来源】：

本文版权归作者所有，未经授权不得转载。【作者：唐霜】

<PageBox>
  <PageBar>
    <PageBackButton>
      <BackIcon />
    </PageBackButton>
    <Title>标题xxx</Title>
    <PageAction>
      <MoreIcon />
    </PageAction>
  </PageBar>
  <PageContent>
      ......
  </PageContent>
</PageBox>

上面这份描述在不同端上的页面结构。虽然P【版权所有】唐霜 www.tangshuang.net未经授权，禁止复制转载。C上和APP上页面的界面长的不同，但是它本文作者：唐霜，转载请注明出处。【版权所有，侵权必究】们的描述可以相同，这份描述并不是它的布局【版权所有】唐霜 www.tangshuang.net【原创不易，请尊重版权】，而是告诉构建工具，这个页面需要哪些元素原创内容，盗版必究。【原创内容，转载请注明出处】，本质上就是载入对应的组件，而PC上和A【原创不易，请尊重版权】【本文首发于唐霜的博客】PP上，这些组件的表现形式不同，所以最终原创内容，盗版必究。著作权归作者所有，禁止商业用途转载。呈现出来的界面就不同。

这需要我们在基础设施层和应用层，做大量的本文作者：唐霜，转载请注明出处。本文作者：唐霜，转载请注明出处。工作封装组件。相同代码在不同端的不同实现【关注微信公众号：wwwtangshuangnet】原创内容，盗版必究。，可以使用扩展、原型链侵入、高阶组件等方【原创内容，转载请注明出处】原创内容，盗版必究。法。再配合上构建工具链，我们就可以做到一转载请注明出处：www.tangshuang.net【未经授权禁止转载】套代码多端运行。

具体界面交互实现

承接上文，我们需要在基础设施层和应用层封【原创不易，请尊重版权】【版权所有】唐霜 www.tangshuang.net装大量的基础UI组件和业务组件。完成这项【关注微信公众号：wwwtangshuangnet】转载请注明出处：www.tangshuang.net工作的过程是很漫长的，不过我们可以随着业【转载请注明来源】【访问 www.tangshuang.net 获取更多精彩内容】务开发的深入，不断的补全这些组件。在组件本文版权归作者所有，未经授权不得转载。【作者：唐霜】完成封装后，我们常常只需要关注页面的组合本文版权归作者所有，未经授权不得转载。未经授权，禁止复制转载。，在页面中按照抽象视图的表达，实现我们想【版权所有】唐霜 www.tangshuang.net【作者：唐霜】要的业务和交互的绑定。在具体业务的页面中【访问 www.tangshuang.net 获取更多精彩内容】【原创内容，转载请注明出处】，我们实际上工作量会变得很少，而组件一旦【本文首发于唐霜的博客】未经授权，禁止复制转载。完成之后，我们又很少改动，这就会导致一个【访问 www.tangshuang.net 获取更多精彩内容】【未经授权禁止转载】和我们前端直觉相反的现象——大部分时间在原创内容，盗版必究。【转载请注明来源】做业务，少量的时间在写UI。

【原创不易，请尊重版权】著作权归作者所有，禁止商业用途转载。著作权归作者所有，禁止商业用途转载。【原创不易，请尊重版权】

注意点

前端实施DDD的过程是漫长的，而且没有标【版权所有，侵权必究】【版权所有，侵权必究】准的做法，我们只能在观察完整体架构和代码【关注微信公众号：wwwtangshuangnet】【未经授权禁止转载】模型之后说“这是符合DDD理念的项目工程原创内容，盗版必究。本文作者：唐霜，转载请注明出处。”，但在此之前，我们不知道应该怎么做，我本文作者：唐霜，转载请注明出处。【本文受版权保护】们唯一能做的，就是做好战略设计和战术设计【作者：唐霜】【转载请注明来源】，尽可能考虑到业务的扩展性。但是，经过上著作权归作者所有，禁止商业用途转载。【原创内容，转载请注明出处】文的阐述，我想你已经发现基于DDD理念进本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net行前端编程，已经和我们所熟知的前端编程模本文作者：唐霜，转载请注明出处。【未经授权禁止转载】式，发生了非常大的变化。我们需要重新认知【作者：唐霜】【转载请注明来源】前端编程范式，打破固有从UI出发的思维，【关注微信公众号：wwwtangshuangnet】【作者：唐霜】先梳理业务，进行领域建模，自下而上的构建著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。应用，传统通过一个脚手架初始化我们的项目本文作者：唐霜，转载请注明出处。【访问 www.tangshuang.net 获取更多精彩内容】的做法，已经远远不够了。

我们需要注意，在构建领域模型时，一定要从未经授权，禁止复制转载。【本文首发于唐霜的博客】真实的业务出发，按照限界上下文的划分去构【本文受版权保护】原创内容，盗版必究。建领域模型，而绝对不可以面向后端接口进行【作者：唐霜】本文作者：唐霜，转载请注明出处。建模。需要提醒的是，限界上下文的划分有一【本文首发于唐霜的博客】【未经授权禁止转载】定难度，我们需要细心和耐心，同时应该多和【作者：唐霜】【作者：唐霜】业务人员产品人员沟通。另外，一个非常有意【原创不易，请尊重版权】转载请注明出处：www.tangshuang.net思的点在于，好的命名，有利于项目代码的持【访问 www.tangshuang.net 获取更多精彩内容】著作权归作者所有，禁止商业用途转载。续维护，坏的命名是一场灾难，我们应该在发本文作者：唐霜，转载请注明出处。【关注微信公众号：wwwtangshuangnet】现坏命名的时候，立即修改它，如果这个命名【版权所有】唐霜 www.tangshuang.net【原创内容，转载请注明出处】是与后端耦合的，我们应该在前端建立map原创内容，盗版必究。未经授权，禁止复制转载。ping来使用前端自己的好命名，记住，“【版权所有】唐霜 www.tangshuang.net【版权所有】唐霜 www.tangshuang.net命名决定命运”。

转载请注明出处：www.tangshua未经授权，禁止复制转载。原创内容，盗版必究。ng.net【原创内容，转载请注明出处】

基于DDD的投资系统前端架构设计实战

投资系统是面向投资活动参与者的管理系统，【本文首发于唐霜的博客】【转载请注明来源】由于业务复杂，参与的人员角色众多，因此，【未经授权禁止转载】【关注微信公众号：wwwtangshuangnet】是一种需要花很多精力去构建的系统。接下来【版权所有】唐霜 www.tangshuang.net转载请注明出处：www.tangshuang.net我们就用DDD的方法论，来分析我们应该如【未经授权禁止转载】未经授权，禁止复制转载。何去设计投资系统的前端架构。

业务梳理

首先，我们需要将我们要准备实现的系统的业本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net务进行梳理，该系统的愿景是什么，想要为它【访问 www.tangshuang.net 获取更多精彩内容】【访问 www.tangshuang.net 获取更多精彩内容】的用户提供什么价值，从哪些方面去体现，将【访问 www.tangshuang.net 获取更多精彩内容】未经授权，禁止复制转载。会实现哪些能力，哪些不需要或需要等到未来【关注微信公众号：wwwtangshuangnet】【版权所有】唐霜 www.tangshuang.net实现等等。

对于投资这件事而言，有非常大的学问，但对著作权归作者所有，禁止商业用途转载。【版权所有】唐霜 www.tangshuang.net于一个管理系统而言，我们需要知道，我们要本文作者：唐霜，转载请注明出处。【未经授权禁止转载】面对的是三大类的投资：一级市场投资、二级【本文首发于唐霜的博客】著作权归作者所有，禁止商业用途转载。市场投资、基金投资。其中一级市场投资最复【版权所有，侵权必究】著作权归作者所有，禁止商业用途转载。杂，从市场中发现一家有价值的公司，到与【作者：唐霜】著作权归作者所有，禁止商业用途转载。该公司调查，内部讨论，TS，DD，向上级【转载请注明来源】【本文首发于唐霜的博客】提出投资建议，审批，进入投资决策，交割，原创内容，盗版必究。【原创不易，请尊重版权】签署协议条款，交易，付款……这一通下来，【访问 www.tangshuang.net 获取更多精彩内容】原创内容，盗版必究。一年半载就过去了。在这过程中，存在各种业本文作者：唐霜，转载请注明出处。【版权所有，侵权必究】务上的特殊性，例如有些阶段在某种情况下可【版权所有】唐霜 www.tangshuang.net转载请注明出处：www.tangshuang.net以跳过，支付的金额会受到监管的限制，审批【原创不易，请尊重版权】著作权归作者所有，禁止商业用途转载。走线上还是线下，等等一系列的特殊逻辑。完【转载请注明来源】原创内容，盗版必究。成投资后还需要做投后管理，分析投资是否产【未经授权禁止转载】本文版权归作者所有，未经授权不得转载。生了足够的回报。过程中还要对参与投资的投【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。资人进行评价，以评估在这次投资中他们作出【转载请注明来源】【本文首发于唐霜的博客】了多少贡献。而二级市场投资，还要考虑从庞【关注微信公众号：wwwtangshuangnet】【版权所有，侵权必究】大的数据中挖掘投资的目标，投资的流程和一【转载请注明来源】【版权所有，侵权必究】级市场也完全不同。此外，还有一种情况是把【版权所有】唐霜 www.tangshuang.net【原创不易，请尊重版权】二级市场买入卖出作为类似一级市场的方式进【原创内容，转载请注明出处】【本文首发于唐霜的博客】行，把二级市场作为交易方式，但是这类被投【转载请注明来源】【本文首发于唐霜的博客】公司已经上市了，又不具备一级市场公司的特【原创不易，请尊重版权】【未经授权禁止转载】性，又是很复杂的特殊性。基金投资则主要是【作者：唐霜】原创内容，盗版必究。针对投资一级市场的基金（Fund of 转载请注明出处：www.tangshuang.net【未经授权禁止转载】Fund），要考虑GP、LP，是否采用S著作权归作者所有，禁止商业用途转载。【原创不易，请尊重版权】PV架构，投资过程中被投基金所投资的公司本文作者：唐霜，转载请注明出处。【原创内容，转载请注明出处】是否与我已投的公司存在重叠，等等问题。

原创内容，盗版必究。未经授权，禁止复制转载。

面对三种类型的投资，我们需要从中挖掘出共本文作者：唐霜，转载请注明出处。本文版权归作者所有，未经授权不得转载。性和个性，建立我们的投资领域模型。

【未经授权禁止转载】本文作者：唐霜，转载请注明出处。

除了投资，系统还要负责跟进与投资相关的其未经授权，禁止复制转载。【关注微信公众号：wwwtangshuangnet】他工作，例如解决投资审批相关的审批流，解本文版权归作者所有，未经授权不得转载。本文版权归作者所有，未经授权不得转载。决投后分析的数据看板，解决投资纠纷的条款【本文首发于唐霜的博客】本文版权归作者所有，未经授权不得转载。摘要，解决项目成员贡献度的贡献度算法等等著作权归作者所有，禁止商业用途转载。【作者：唐霜】。

【原创不易，请尊重版权】【转载请注明来源】【本文受版权保护】

为了梳理清楚业务，我们需要和业务人员产品【转载请注明来源】【访问 www.tangshuang.net 获取更多精彩内容】人员一起，通过事件风暴、领域故事等，把我原创内容，盗版必究。原创内容，盗版必究。们系统将要涉及的方面方面先一一列举出来，【未经授权禁止转载】【原创不易，请尊重版权】虽然此时还很混乱，但是我们已经确保我们的【访问 www.tangshuang.net 获取更多精彩内容】【原创不易，请尊重版权】系统将要有什么，不会有什么。

限界上下文确定

首先是限界上下文的划分，我们已经把所有涉【原创内容，转载请注明出处】本文版权归作者所有，未经授权不得转载。及的方方面面都列举出来了，接下来我们就是【版权所有，侵权必究】本文版权归作者所有，未经授权不得转载。把这些一个一个的点进行区分，通过区分，来【未经授权禁止转载】【原创不易，请尊重版权】画出界线。不过有的时候，一个东西看上去是【未经授权禁止转载】【本文受版权保护】两个限界上下文共有的，此时我们要额外当心【原创不易，请尊重版权】【原创不易，请尊重版权】，这是一个陷阱，要么是我们应该把这个东西著作权归作者所有，禁止商业用途转载。【作者：唐霜】在进行细化，实际上它应该是两种完全不同的【转载请注明来源】本文作者：唐霜，转载请注明出处。东西，要么我们一定漏掉了什么东西，以至于【原创内容，转载请注明出处】著作权归作者所有，禁止商业用途转载。我们在两个限界上下文之间丢失了一个其他限著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。界上下文。

【转载请注明来源】【关注微信公众号：wwwtangshua原创内容，盗版必究。原创内容，盗版必究。ngnet】【作者：唐霜】【访问 www.tangshuang.n本文版权归作者所有，未经授权不得转载。本文版权归作者所有，未经授权不得转载。et 获取更多精彩内容】

投资系统限界上下文划分示意图

【原创不易，请尊重版权】【本文首发于唐霜的博客】【访问 www.tangshuang.n未经授权，禁止复制转载。【访问 www.tangshuang.net 获取更多精彩内容】et 获取更多精彩内容】本文作者：唐霜，转载请注明出处。

原创内容，盗版必究。未经授权，禁止复制转载。转载请注明出处：www.tangshua【本文首发于唐霜的博客】【未经授权禁止转载】ng.net未经授权，禁止复制转载。

上图只是一个举例，在真实的系统设计中，我本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。们实际上会有更多领域更多上下文，这里也只原创内容，盗版必究。本文版权归作者所有，未经授权不得转载。列举了业务关联部分，实际上，我们还有更多本文版权归作者所有，未经授权不得转载。【本文首发于唐霜的博客】支撑域和通用域，这些都没有展示出来。

【原创内容，转载请注明出处】著作权归作者所有，禁止商业用途转载。原创内容，盗版必究。【原创不易，请尊重版权】

完成划分之后，我们要找出限界上下文之间的【原创内容，转载请注明出处】本文版权归作者所有，未经授权不得转载。映射，实际上，这种映射是非常容易的，只不【访问 www.tangshuang.net 获取更多精彩内容】【关注微信公众号：wwwtangshuangnet】过有的时候我们不能忽略细节。

【关注微信公众号：wwwtangshua【原创不易，请尊重版权】本文作者：唐霜，转载请注明出处。ngnet】著作权归作者所有，禁止商业用途转载。【未经授权禁止转载】

【原创内容，转载请注明出处】【转载请注明来源】【转载请注明来源】【访问 www.tangshuang.n著作权归作者所有，禁止商业用途转载。【未经授权禁止转载】et 获取更多精彩内容】

本文作者：唐霜，转载请注明出处。【原创内容，转载请注明出处】未经授权，禁止复制转载。未经授权，禁止复制转载。

构建领域模型

接下来，我们需要对所有业务对象、行为、关【作者：唐霜】原创内容，盗版必究。联进行领域建模。这个过程中，理论上我们应【版权所有】唐霜 www.tangshuang.net【版权所有】唐霜 www.tangshuang.net该先进行统一语言的建模，例如采用UML将【未经授权禁止转载】【版权所有，侵权必究】系统中有关的对象、操作、联动都表达出来，【作者：唐霜】著作权归作者所有，禁止商业用途转载。但在现实中，我们往往用不上UML，我们可本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。能会提供一大堆的excel表格，里面给出【转载请注明来源】【本文首发于唐霜的博客】了每一组对象，在不同场景下，有什么字段，本文版权归作者所有，未经授权不得转载。【本文受版权保护】有哪些选项，存在某些逻辑，例如字段类型、【转载请注明来源】未经授权，禁止复制转载。长度、是否必填、与其他字段的联动关系、存本文作者：唐霜，转载请注明出处。【原创内容，转载请注明出处】在问题时的描述等等。这看上去与我们编程意【原创不易，请尊重版权】转载请注明出处：www.tangshuang.net义上的“建模”没有任何关系，但是实际上，【本文受版权保护】未经授权，禁止复制转载。这一步不可或缺，必须执行。

当我们已经沉淀出较为完整的excel、导【原创内容，转载请注明出处】【作者：唐霜】图、文档之后，我们还需要再次基于限界上下【原创不易，请尊重版权】【作者：唐霜】文的映射对它们进行review，在脑海中【关注微信公众号：wwwtangshuangnet】【本文受版权保护】去构思系统实现过程中可能遇到的问题，或者本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net不同文档之间可能存在的冲突，甚至在交互上【原创内容，转载请注明出处】【原创不易，请尊重版权】可能存在的问题，并充分与产品人员进行讨论原创内容，盗版必究。本文作者：唐霜，转载请注明出处。，基于这些问题，我们可能会重新思考，文档【原创不易，请尊重版权】【转载请注明来源】中的这些业务是否可以采取另外一种形式在系【原创内容，转载请注明出处】未经授权，禁止复制转载。统中呈现，并由此可能提出的第二版领域模型【原创不易，请尊重版权】未经授权，禁止复制转载。。

接下来就是代码。

未经授权，禁止复制转载。转载请注明出处：www.tangshua【原创不易，请尊重版权】未经授权，禁止复制转载。ng.net【原创内容，转载请注明出处】原创内容，盗版必究。

将我们整理好的资料，用代码表达出来。前文【未经授权禁止转载】著作权归作者所有，禁止商业用途转载。已经介绍了前端进行领域建模的方法。我们可【本文受版权保护】【本文受版权保护】以使用 TySheMo 来描述我们的字段【未经授权禁止转载】【本文受版权保护】和实体，构建实体网络，并且可以结合前端需【转载请注明来源】【转载请注明来源】要的一些特殊属性，构建出关于字段的完整原创内容，盗版必究。【版权所有】唐霜 www.tangshuang.netMeta，而这些 Meta 可以让团队成【版权所有，侵权必究】著作权归作者所有，禁止商业用途转载。员对该字段有一个完整的认知。此处我们需要转载请注明出处：www.tangshuang.net转载请注明出处：www.tangshuang.net注意一个点，“场景”的概念，在开发中极为【转载请注明来源】【原创不易，请尊重版权】重要，因为所有字段的业务逻辑，在不同场景【本文受版权保护】【转载请注明来源】下都是不同的，这一点我在《前端业务建模的内涵》一文中有详细的阐述，有机会你可以阅读以未经授权，禁止复制转载。【作者：唐霜】下。以必填逻辑为例，订单的创建地址是非必【访问 www.tangshuang.net 获取更多精彩内容】【转载请注明来源】填的，但是到了付款阶段是必填的，否则用户【本文受版权保护】著作权归作者所有，禁止商业用途转载。就收不到货了。一个字段在不同阶段其必填逻【未经授权禁止转载】【作者：唐霜】辑不同，再抽象一下，阶段、状态、类型等等【原创不易，请尊重版权】著作权归作者所有，禁止商业用途转载。都是可被区分的，我们把这类可用于区分的东转载请注明出处：www.tangshuang.net【未经授权禁止转载】西称为“场景”，每一个场景都意味着某些逻【本文首发于唐霜的博客】【版权所有】唐霜 www.tangshuang.net辑上的区别。在 TySheMo 中，我们【版权所有，侵权必究】【访问 www.tangshuang.net 获取更多精彩内容】使用 SceneMeta 来实现这种场景转载请注明出处：www.tangshuang.net未经授权，禁止复制转载。区分的设计。基于这种设计，Meta 是完原创内容，盗版必究。原创内容，盗版必究。整的，而非割裂的，你的所有逻辑都在一个著作权归作者所有，禁止商业用途转载。【原创内容，转载请注明出处】Meta 中，而不会在不同场景下定义不同【本文受版权保护】原创内容，盗版必究。的 Meta，这将有利于一个字段逻辑的可【版权所有】唐霜 www.tangshuang.net【原创内容，转载请注明出处】持续维护。

本文版权归作者所有，未经授权不得转载。【关注微信公众号：wwwtangshua著作权归作者所有，禁止商业用途转载。【本文首发于唐霜的博客】ngnet】

服务则是基于 Nautil 的 Serv本文作者：唐霜，转载请注明出处。著作权归作者所有，禁止商业用途转载。ice 实现，服务是为业务服务的，当然，【未经授权禁止转载】【未经授权禁止转载】这里“为业务服务”其实体现了两点，一是指【版权所有】唐霜 www.tangshuang.net【本文首发于唐霜的博客】它的代码里面描述的主要是业务或者业务相关【本文首发于唐霜的博客】【版权所有，侵权必究】的技术实现，二是它不是业务核心是相对而言【版权所有，侵权必究】【作者：唐霜】更边缘的实现。不过，从技术上，基于 Se【本文受版权保护】转载请注明出处：www.tangshuang.netrvice 我们还需要更多技术上的实现，转载请注明出处：www.tangshuang.net【原创内容，转载请注明出处】例如 MessageQueueServi【关注微信公众号：wwwtangshuangnet】【关注微信公众号：wwwtangshuangnet】ce, EventService 等等。

另外，我们可能还要创建很多函数来做业务逻【未经授权禁止转载】未经授权，禁止复制转载。辑的封装，例如一些逻辑判断的函数，或者针【版权所有，侵权必究】著作权归作者所有，禁止商业用途转载。对业务上数据处理的函数，这些我们可以称为【访问 www.tangshuang.net 获取更多精彩内容】转载请注明出处：www.tangshuang.net领域工厂函数。还有基于 react ho【本文受版权保护】【关注微信公众号：wwwtangshuangnet】oks 的逻辑封装，不过我一直提倡 ho【原创不易，请尊重版权】【版权所有】唐霜 www.tangshuang.netoks 是试图层的状态控制器，不属于业务【原创不易，请尊重版权】本文作者：唐霜，转载请注明出处。层面的编程，因为它必须在 react 平著作权归作者所有，禁止商业用途转载。【关注微信公众号：wwwtangshuangnet】台上运行，我们应该尽可能的把业务封装为平【作者：唐霜】本文版权归作者所有，未经授权不得转载。台无关的，这样才能在将来的项目发展中，可转载请注明出处：www.tangshuang.net原创内容，盗版必究。以直接复用领域模型。

【访问 www.tangshuang.n【转载请注明来源】【本文首发于唐霜的博客】et 获取更多精彩内容】本文作者：唐霜，转载请注明出处。

分层架构设计

我们将整个项目分为基础设施层、领域层、应【关注微信公众号：wwwtangshuangnet】【本文受版权保护】用层、用户界面层，但是实际上它们并不可能【转载请注明来源】【本文受版权保护】存在绝对明显的界线，关键是我们要梳理好依【作者：唐霜】【转载请注明来源】赖关系，避免依赖的混乱，自底向顶的去构建本文作者：唐霜，转载请注明出处。【关注微信公众号：wwwtangshuangnet】我们的系统（多个应用门户）。其中，领域层著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。的全部+应用层的部分，组成了有关业务的全【本文首发于唐霜的博客】未经授权，禁止复制转载。部。我们基于这些代码，可以完全了解业务逻【本文首发于唐霜的博客】【作者：唐霜】辑，也就可以复原我们的实际业务本身。应用【原创内容，转载请注明出处】【关注微信公众号：wwwtangshuangnet】层中，我们会将领域模型接入进来，并按照需【关注微信公众号：wwwtangshuangnet】【原创不易，请尊重版权】求文档中的交互描述组合它们，以完成和业务【未经授权禁止转载】【原创不易，请尊重版权】相关的交互处理。

【作者：唐霜】【转载请注明来源】本文作者：唐霜，转载请注明出处。

我在多处提出过，对于前端而言，交互也是有【本文受版权保护】【版权所有，侵权必究】业务的，这些交互往往处于某种事件流中，例【版权所有】唐霜 www.tangshuang.net【原创内容，转载请注明出处】如“用户点击xx之后，需要弹出上传文件的【版权所有】唐霜 www.tangshuang.net【本文首发于唐霜的博客】对话框，必须上传相关文件之后，才能进入”【访问 www.tangshuang.net 获取更多精彩内容】【访问 www.tangshuang.net 获取更多精彩内容】。这里，我们实际上没有具体的界面，但是，【转载请注明来源】转载请注明出处：www.tangshuang.net整个交互的过程是非常明确的，而且，这个过转载请注明出处：www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】程是业务，而不是纯粹的交互。因此，我提出未经授权，禁止复制转载。本文作者：唐霜，转载请注明出处。要建立交互模型，本质上，交互模型是业务模【本文首发于唐霜的博客】【关注微信公众号：wwwtangshuangnet】型，而非视图模型。并且，交互模型一定是针【原创不易，请尊重版权】转载请注明出处：www.tangshuang.net对某一场景的建模，是非通用的业务，而是具未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。体的特殊的业务。全部的领域层，加上这里的著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。交互模型，实际上构成了该业务在该场景下的【原创内容，转载请注明出处】原创内容，盗版必究。完整业务过程描述，这些部分应该是在多端下【作者：唐霜】【本文首发于唐霜的博客】一致的，PC和APP上，应该共用这份代码【版权所有】唐霜 www.tangshuang.net著作权归作者所有，禁止商业用途转载。，保证业务的一致性。

本文版权归作者所有，未经授权不得转载。【本文首发于唐霜的博客】【转载请注明来源】【作者：唐霜】

应用层剩下的部分，则是完成该业务该场景下【本文受版权保护】【版权所有，侵权必究】有关UI的全部，因此，应用层的输出产物，原创内容，盗版必究。【原创内容，转载请注明出处】是微前端中的一个子应用。理论上，这个子应【作者：唐霜】【转载请注明来源】用只要做一些简单的环境，就可以运行起来。【原创内容，转载请注明出处】转载请注明出处：www.tangshuang.net但是在代码层面，它们是分端的，我一般分为【版权所有，侵权必究】【本文受版权保护】pc、native、mobile、wec本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。hat这几个，其中mobile指h5或h未经授权，禁止复制转载。【作者：唐霜】ybrid混合开发中的页面，wechat著作权归作者所有，禁止商业用途转载。【未经授权禁止转载】是指微信小程序，其他的小程序平台也可以对【本文首发于唐霜的博客】【转载请注明来源】应去做。也就是说，应用层的产物——一个业【关注微信公众号：wwwtangshuangnet】原创内容，盗版必究。务模块——就是这些不同端具体实现的集合。

【本文受版权保护】本文作者：唐霜，转载请注明出处。

用户界面层则是用户的入口，其产物就是一个本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。个的Application，PC的、微信【访问 www.tangshuang.net 获取更多精彩内容】未经授权，禁止复制转载。小程序的、h5的，每一个用户的入口，我们【未经授权禁止转载】著作权归作者所有，禁止商业用途转载。都可以称之为一个App。实际上，我们需要本文版权归作者所有，未经授权不得转载。原创内容，盗版必究。自主实现微前端基座的能力，来协调不同模块【未经授权禁止转载】【转载请注明来源】。而基础设施层，则是会被其他所有层的代码【转载请注明来源】【访问 www.tangshuang.net 获取更多精彩内容】所使用。

【作者：唐霜】【未经授权禁止转载】【本文首发于唐霜的博客】转载请注明出处：www.tangshua本文作者：唐霜，转载请注明出处。【转载请注明来源】ng.net

代码模型设计

我们不会为每一层划分一个目录，然后每一个未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。目录分别放上述对应的模型或UI。相反，我【关注微信公众号：wwwtangshuangnet】【原创内容，转载请注明出处】们组织代码，是从开发者阅读代码、寻找逻辑著作权归作者所有，禁止商业用途转载。【转载请注明来源】、持续维护的角度考虑。我们尽可能让我们的未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。代码不要处于孤岛状态（当然，有些设计模式【原创内容，转载请注明出处】【作者：唐霜】是允许孤岛代码的存在），而应该让代码按照著作权归作者所有，禁止商业用途转载。【原创不易，请尊重版权】洋葱架构的设计，建立起层层向下的依赖关系原创内容，盗版必究。【版权所有，侵权必究】，依赖的顺序不可以相反。我认为，我们的代本文作者：唐霜，转载请注明出处。本文作者：唐霜，转载请注明出处。码首先需要如此划分：

未经授权，禁止复制转载。

【未经授权禁止转载】

著作权归作者所有，禁止商业用途转载。

libs 基础层的一些实现，主要是第三方【原创内容，转载请注明出处】【原创内容，转载请注明出处】的封装和自建的一些工具

【关注微信公众号：wwwtangshua本文作者：唐霜，转载请注明出处。【关注微信公众号：wwwtangshuangnet】ngnet】

【访问 www.tangshuang.n本文版权归作者所有，未经授权不得转载。本文作者：唐霜，转载请注明出处。et 获取更多精彩内容】

【转载请注明来源】

原创内容，盗版必究。

本文版权归作者所有，未经授权不得转载。

components 基础层的逻辑组件，著作权归作者所有，禁止商业用途转载。【本文受版权保护】以及UI组件的抽象（UI组件需要依赖不同著作权归作者所有，禁止商业用途转载。【本文首发于唐霜的博客】端，其实现在各自端实现）

本文版权归作者所有，未经授权不得转载。

转载请注明出处：www.tangshua【转载请注明来源】未经授权，禁止复制转载。ng.net

hooks 通用的逻辑hooks函数

著作权归作者所有，禁止商业用途转载。

未经授权，禁止复制转载。

modules 应用层业务模块的具体实现

未经授权，禁止复制转载。

【本文受版权保护】

@implements 不同端的具体实现【未经授权禁止转载】原创内容，盗版必究。，以孤岛代码形式进行原型链侵入

【作者：唐霜】

未经授权，禁止复制转载。

本文作者：唐霜，转载请注明出处。

【本文受版权保护】

apps 用户界面层的应用

本文版权归作者所有，未经授权不得转载。

未经授权，禁止复制转载。

从顶层来看，我们只关注代码的整体分类，而【作者：唐霜】【作者：唐霜】不在乎最终的用户入口。不过，从整体看，我【本文受版权保护】原创内容，盗版必究。们更相信，基础设施层的建设，会无缝的穿插著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。在其他所有层中，因此，我们在进行代码的安原创内容，盗版必究。【转载请注明来源】排时，不要只关注分层，而应该以技术为指导【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。，同时保持思考DDD的设计。

【本文首发于唐霜的博客】原创内容，盗版必究。著作权归作者所有，禁止商业用途转载。【转载请注明来源】

之所以叫 subjects 而非 dom转载请注明出处：www.tangshuang.net【转载请注明来源】ains 是因为我认为对于前端而言，在代【本文受版权保护】【作者：唐霜】码管理层面，即使非领域的代码，可能也需要【版权所有】唐霜 www.tangshuang.net【关注微信公众号：wwwtangshuangnet】集中管理，例如我们有一个 investm【版权所有，侵权必究】著作权归作者所有，禁止商业用途转载。ent 的 subject，里面不仅有未经授权，禁止复制转载。【原创不易，请尊重版权】metas, models, servi【原创不易，请尊重版权】【未经授权禁止转载】ces, controllers 还有【本文首发于唐霜的博客】本文作者：唐霜，转载请注明出处。components, views, h【原创不易，请尊重版权】【关注微信公众号：wwwtangshuangnet】ooks, typings，也就是说，有未经授权，禁止复制转载。【本文受版权保护】很多前端的内容也需要聚合到 invest原创内容，盗版必究。【转载请注明来源】ment 目录中一起管理，因此，这里的代【访问 www.tangshuang.net 获取更多精彩内容】【未经授权禁止转载】码不是单纯领域的代码。

【本文受版权保护】本文版权归作者所有，未经授权不得转载。原创内容，盗版必究。

modules 目录则主要是根据具体场景本文版权归作者所有，未经授权不得转载。本文作者：唐霜，转载请注明出处。来构筑业务模块，我一般的设计如下：

【转载请注明来源】【未经授权禁止转载】【作者：唐霜】本文版权归作者所有，未经授权不得转载。

investment-portfolio
- controllers
- views
- @platforms
  - pc
    - supply
    - list
    - append
    - detail
  - mobile
  - native
  - wechat

【关注微信公众号：wwwtangshua本文版权归作者所有，未经授权不得转载。【关注微信公众号：wwwtangshuangnet】ngnet】

著作权归作者所有，禁止商业用途转载。

首先是要分端，因为不同端端实现是不同的，原创内容，盗版必究。【原创内容，转载请注明出处】特别是native和wechat的实现，【本文首发于唐霜的博客】本文作者：唐霜，转载请注明出处。与web的实现差距比较大。

在用户界面层apps中，我们每一个应用所未经授权，禁止复制转载。【原创不易，请尊重版权】对应的端可能都不同，例如我们在手机上会有【转载请注明来源】著作权归作者所有，禁止商业用途转载。两个app，这两个app我们会用两个目录【关注微信公众号：wwwtangshuangnet】【作者：唐霜】作为入口，不过等下我们会讲到，它们走相同未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。的构建工具链。

项目工程设计

在《复杂企业应用前端架构探索》一文中，我【访问 www.tangshuang.net 获取更多精彩内容】本文版权归作者所有，未经授权不得转载。详细阐述了项目工程的洋葱图，如下。我们将转载请注明出处：www.tangshuang.net【原创不易，请尊重版权】进入到最外层“前端工程”的探讨。我们要做未经授权，禁止复制转载。【关注微信公众号：wwwtangshuangnet】更多的建设，来支持我们多端同构的能力。

【转载请注明来源】本文作者：唐霜，转载请注明出处。【未经授权禁止转载】【未经授权禁止转载】

在系统本身的实现代码之外，我们还需要有项【原创内容，转载请注明出处】转载请注明出处：www.tangshuang.net目的代码，包括配置代码、构建代码、规范代本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。码、文档等等。例如我们需要有webpac【关注微信公众号：wwwtangshuangnet】【原创不易，请尊重版权】k.config.js, babelrc【原创内容，转载请注明出处】【版权所有】唐霜 www.tangshuang.net, gulpfile等等，还会使用工具实未经授权，禁止复制转载。【关注微信公众号：wwwtangshuangnet】现git hooks，还会使用eslin【原创不易，请尊重版权】【本文受版权保护】t, tsconfig等等，还会使用测试【原创不易，请尊重版权】【本文受版权保护】工具，还会使用CI/CD，等等。这些都是原创内容，盗版必究。本文作者：唐霜，转载请注明出处。实现系统功能本身之外的东西，但是它们在项转载请注明出处：www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】目中不可获取。

【作者：唐霜】【未经授权禁止转载】

其中需要重点讲的是构建工具链，因为基于构【版权所有】唐霜 www.tangshuang.net未经授权，禁止复制转载。建工具链，甚至会影响我们怎么写代码，甚至【作者：唐霜】【转载请注明来源】会约束我们在某些具体位置上的代码实现方式【本文受版权保护】【版权所有】唐霜 www.tangshuang.net。在本文中，最重要的一点，是实现多端同构【原创内容，转载请注明出处】转载请注明出处：www.tangshuang.net的能力，也就是在手机端，我们希望一套代码本文版权归作者所有，未经授权不得转载。转载请注明出处：www.tangshuang.net，可以输出h5、react native【作者：唐霜】【版权所有，侵权必究】、微信小程序等可以多端运行的能力。这里不著作权归作者所有，禁止商业用途转载。【原创内容，转载请注明出处】仅要我们在工具上，拥有不同入口，走不通构【未经授权禁止转载】【转载请注明来源】建流的能力，还要求我们进行具体的运行环境【原创内容，转载请注明出处】转载请注明出处：www.tangshuang.net建设，例如react native，你需原创内容，盗版必究。著作权归作者所有，禁止商业用途转载。要有ios和android的开发能力，为【原创不易，请尊重版权】未经授权，禁止复制转载。app的外壳开发具体的能力，你需要有一套【原创内容，转载请注明出处】【本文受版权保护】将我们的UI映射到具体小程序平台上的组件本文作者：唐霜，转载请注明出处。【未经授权禁止转载】，以及对应的调用能力。

结语

本文详细阐述了我在前端运用DDD理念进行【版权所有】唐霜 www.tangshuang.net【作者：唐霜】设计和实战的全部，相信你读毕能形成一个基【原创不易，请尊重版权】【本文首发于唐霜的博客】本的轮廓，知道在前端去实践DDD可能需要【版权所有，侵权必究】原创内容，盗版必究。经历哪些过程，只是在具体实践过程中，还要未经授权，禁止复制转载。【关注微信公众号：wwwtangshuangnet】去思考具体细节应该怎么做。但是，还是回到【本文首发于唐霜的博客】原创内容，盗版必究。文章开头所讲，DDD是方法论，而非架构或【转载请注明来源】【版权所有，侵权必究】技术解决方案，可以说DDD几乎没有解决任【未经授权禁止转载】原创内容，盗版必究。何技术问题。基于DDD去思考和设计我们的原创内容，盗版必究。【关注微信公众号：wwwtangshuangnet】系统架构，一不能使我们的系统架构或者代码【本文首发于唐霜的博客】【版权所有，侵权必究】写作变简单，二不能降低我们的开发时间做到【关注微信公众号：wwwtangshuangnet】本文版权归作者所有，未经授权不得转载。降本增效，三也不能让我们立竿见影看到系统著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。改造或重构的效果（起码在汇报时无法给出提【未经授权禁止转载】【版权所有】唐霜 www.tangshuang.net示的数据）。然而，它可以让我们的架构更清原创内容，盗版必究。未经授权，禁止复制转载。晰，依赖更合理，对于我们业务需求的不断发未经授权，禁止复制转载。【转载请注明来源】展，增量式的开发，可持续的长期维护，有着本文版权归作者所有，未经授权不得转载。原创内容，盗版必究。非常大的意义，基于这一意义，它在后期的开【关注微信公众号：wwwtangshuangnet】本文版权归作者所有，未经授权不得转载。发中发挥的价值更大，不能在短时间内看到的著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。成果，都可以在后续日积月累的增量过程中显原创内容，盗版必究。【未经授权禁止转载】现出来，例如降低维护成本，数据越来越漂亮著作权归作者所有，禁止商业用途转载。【版权所有】唐霜 www.tangshuang.net等等。最后的最后，前端的DDD实践与后端【版权所有，侵权必究】【关注微信公众号：wwwtangshuangnet】的必然存在不同，这是由技术环境所决定的，【未经授权禁止转载】【未经授权禁止转载】不可以套用，当我们受到质疑时，应该坚持自未经授权，禁止复制转载。【原创不易，请尊重版权】己的理解。<完>

【转载请注明来源】本文版权归作者所有，未经授权不得转载。【作者：唐霜】

【版权所有】唐霜 www.tangshuang.net【版权所有】唐霜 www.tangshuang.net【转载请注明来源】本文版权归作者所有，未经授权不得转载。【本文首发于唐霜的博客】【版权所有】唐霜 www.tangshuang.net【版权所有，侵权必究】【转载请注明来源】【本文首发于唐霜的博客】【版权所有，侵权必究】转载请注明出处：www.tangshuang.net【转载请注明来源】【版权所有，侵权必究】【未经授权禁止转载】【原创不易，请尊重版权】【原创不易，请尊重版权】【未经授权禁止转载】转载请注明出处：www.tangshuang.net未经授权，禁止复制转载。【版权所有】唐霜 www.tangshuang.net著作权归作者所有，禁止商业用途转载。【未经授权禁止转载】【版权所有，侵权必究】原创内容，盗版必究。【未经授权禁止转载】转载请注明出处：www.tangshuang.net本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。【原创内容，转载请注明出处】【本文首发于唐霜的博客】【原创内容，转载请注明出处】

如果你觉得本书对你有帮助，通过下方的二维码向我打赏吧，帮助我写出更多有用的内容。

基于DDD的前端项目架构设计与实战

DDD知识体系

DDD的意义

DDD不是什么？

DDD中的基本概念

统一语言

领域模型

架构设计

战略设计和战术设计

后端DDD概览

前端DDD详解

前端DDD与后端的不同

项目工程变更

基于微前端的业务模块拆分

基于构建工具链的聚合应用和多端分发

团队人员分工与职责变更

代码模型变更

领域层代码

业务场景逻辑

业务功能模块

扩展能力

分层架构设计

底层框架封装

团队规范

前端DDD的具体实施

领域建模

交互模型

抽象视图

具体界面交互实现

注意点

基于DDD的投资系统前端架构设计实战

业务梳理

限界上下文确定

构建领域模型

分层架构设计

代码模型设计

项目工程设计

结语