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

本文的所有内容我梳理为一张思维导图，你可著作权归作者所有，禁止商业用途转载。【未经授权禁止转载】以根据这张图，获得大致的内容框架。

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

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

DDD知识体系转载请注明出处：www.tangshuang.net

著作权归作者所有，禁止商业用途转载。【关注微信公众号：wwwtangshuangnet】未经授权，禁止复制转载。原创内容，盗版必究。转载请注明出处：www.tangshuang.net

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

DDD的意义转载请注明出处：www.tangshuang.net

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

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

本文版权归作者所有，未经授权不得转载。【本文受版权保护】未经授权，禁止复制转载。

DDD不是什么？转载请注明出处：www.tangshuang.net

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

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

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

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

【关注微信公众号：wwwtangshuangnet】【转载请注明来源】【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。本文版权归作者所有，未经授权不得转载。

掌握DDD并不能解决我们怎么把这个组件写【本文受版权保护】【本文受版权保护】的非常灵活，也不能解决我们怎么让应用跑起著作权归作者所有，禁止商业用途转载。本文作者：唐霜，转载请注明出处。来性能更好，更不能解决我们如何收集应用错本文版权归作者所有，未经授权不得转载。【版权所有，侵权必究】误日志的问题。它甚至在我们代码层面不会有【作者：唐霜】著作权归作者所有，禁止商业用途转载。任何的呈现，它只呈现在我们团队成员的脑海本文版权归作者所有，未经授权不得转载。转载请注明出处：www.tangshuang.net中。

【本文首发于唐霜的博客】【本文受版权保护】【未经授权禁止转载】【访问 www.tangshuang.net 获取更多精彩内容】

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

DDD中的基本概念【版权所有】唐霜 www.tangshuang.net

转载请注明出处：www.tangshuang.net本文版权归作者所有，未经授权不得转载。【原创不易，请尊重版权】本文作者：唐霜，转载请注明出处。【本文受版权保护】

统一语言【版权所有】唐霜 www.tangshuang.net

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

本文作者：唐霜，转载请注明出处。【未经授权禁止转载】【关注微信公众号：wwwtangshuangnet】

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

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

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

领域模型【未经授权禁止转载】

本文版权归作者所有，未经授权不得转载。本文版权归作者所有，未经授权不得转载。【访问 www.tangshuang.net 获取更多精彩内容】

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

【本文首发于唐霜的博客】原创内容，盗版必究。本文作者：唐霜，转载请注明出处。

领域的规模【转载请注明来源】

本文作者：唐霜，转载请注明出处。著作权归作者所有，禁止商业用途转载。【本文首发于唐霜的博客】【访问 www.tangshuang.net 获取更多精彩内容】

一个系统中，一个领域可以分为多个子域，子著作权归作者所有，禁止商业用途转载。【关注微信公众号：wwwtangshuangnet】域还能分为多个子域。

领域的分类【原创不易，请尊重版权】

【作者：唐霜】【本文受版权保护】【本文首发于唐霜的博客】

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

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

限界上下文未经授权，禁止复制转载。

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

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

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

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

限界上下文的映射，就是将被划分好的不同限原创内容，盗版必究。【关注微信公众号：wwwtangshuangnet】界上下文之间的关联标注出来，同时还要标注【本文受版权保护】【未经授权禁止转载】出它们之间的依赖关系。有了映射，我们就可【未经授权禁止转载】转载请注明出处：www.tangshuang.net以纵览我们系统中各个子域之间关系的全貌。

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

U到D是影响作用方向，D到U是依赖方向【作者：唐霜】

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

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

DDD通过建模来让领域中的事物、行为、关【关注微信公众号：wwwtangshuangnet】【原创内容，转载请注明出处】联确定下来，使之固定化，可以作为代码在系【原创不易，请尊重版权】【本文首发于唐霜的博客】统中被使用。它提供了如下几种建模方案：实【作者：唐霜】【原创内容，转载请注明出处】体、值对象、聚合和聚合根、服务、工厂、仓本文版权归作者所有，未经授权不得转载。【关注微信公众号：wwwtangshuangnet】库（资源库）。这部分内容其实与后端结合比转载请注明出处：www.tangshuang.net著作权归作者所有，禁止商业用途转载。较紧密，前端开发人员往往无法理解。而且D【未经授权禁止转载】本文作者：唐霜，转载请注明出处。DD的方法是面向对象的建模方法，这与前端【版权所有】唐霜 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逻辑；另一方面，在技术上，它可以实现解耦【本文受版权保护】【本文受版权保护】，把原本需要跨领域调用的耦合代码，进行拆【原创不易，请尊重版权】转载请注明出处：www.tangshuang.net分，从而避免代码上的过度耦合。

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

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

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

架构设计【转载请注明来源】

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

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

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

四层架构【本文受版权保护】

本文版权归作者所有，未经授权不得转载。原创内容，盗版必究。【作者：唐霜】【关注微信公众号：wwwtangshuangnet】

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

著作权归作者所有，禁止商业用途转载。转载请注明出处：www.tangshuang.net【作者：唐霜】【访问 www.tangshuang.net 获取更多精彩内容】

【访问 www.tangshuang.net 获取更多精彩内容】未经授权，禁止复制转载。原创内容，盗版必究。本文版权归作者所有，未经授权不得转载。【关注微信公众号：wwwtangshuangnet】

“洋葱架构”【本文首发于唐霜的博客】

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

本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。【关注微信公众号：wwwtangshuangnet】原创内容，盗版必究。【关注微信公众号：wwwtangshuangnet】

六边形架构本文作者：唐霜，转载请注明出处。

【访问 www.tangshuang.net 获取更多精彩内容】原创内容，盗版必究。本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。

也被称为端口与适配器架构，这种架构在洋葱【作者：唐霜】【访问 www.tangshuang.net 获取更多精彩内容】架构基础上，增加了端口和适配器，每一条边原创内容，盗版必究。【本文受版权保护】代表不同类型的短裤，端口要么处理输入，要本文版权归作者所有，未经授权不得转载。【本文受版权保护】么处理输出，每种外界类型，都有一个适配器【未经授权禁止转载】本文版权归作者所有，未经授权不得转载。与之匹配，外界通过接口与内部交互。

【访问 www.tangshuang.net 获取更多精彩内容】转载请注明出处：www.tangshuang.net著作权归作者所有，禁止商业用途转载。【关注微信公众号：wwwtangshuangnet】

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

战略设计和战术设计【转载请注明来源】

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

后端DDD概览未经授权，禁止复制转载。

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

【访问 www.tangshuang.net 获取更多精彩内容】【关注微信公众号：wwwtangshuangnet】【关注微信公众号：wwwtangshuangnet】本文版权归作者所有，未经授权不得转载。【本文首发于唐霜的博客】

基于DDD的方法论，我们一般的工作顺序是【本文受版权保护】【访问 www.tangshuang.net 获取更多精彩内容】：产品愿景、业务场景分析、领域建模、微服【原创不易，请尊重版权】转载请注明出处：www.tangshuang.net务拆分；架构落地、代码模型、工程搭建。

未经授权，禁止复制转载。【本文受版权保护】著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。【原创内容，转载请注明出处】

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

未经授权，禁止复制转载。【转载请注明来源】【未经授权禁止转载】【原创不易，请尊重版权】【未经授权禁止转载】

前端DDD详解未经授权，禁止复制转载。

转载请注明出处：www.tangshuang.net本文版权归作者所有，未经授权不得转载。本文版权归作者所有，未经授权不得转载。【原创内容，转载请注明出处】

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

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

前端DDD与后端的不同【原创内容，转载请注明出处】

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

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

项目工程变更原创内容，盗版必究。

原创内容，盗版必究。转载请注明出处：www.tangshuang.net【本文首发于唐霜的博客】【原创内容，转载请注明出处】

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

【原创内容，转载请注明出处】转载请注明出处：www.tangshuang.net【转载请注明来源】

基于微前端的业务模块拆分【关注微信公众号：wwwtangshuangnet】

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

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

基于构建工具链的聚合应用和多端分发本文作者：唐霜，转载请注明出处。

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

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

团队人员分工与职责变更【本文受版权保护】

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

单一人员负责在整个应用中这里修修那里补补【原创不易，请尊重版权】【本文受版权保护】的分工模式，是没有办法适应DDD的思想的【转载请注明来源】【原创内容，转载请注明出处】。在团队中，一定会存在一部分人员更注重业著作权归作者所有，禁止商业用途转载。【本文受版权保护】务，一部分人更注重技术的分布情况。在DD本文版权归作者所有，未经授权不得转载。【未经授权禁止转载】D思想下的架构情况下，团队人员的合理设定本文作者：唐霜，转载请注明出处。【本文受版权保护】，能够更加有效的发挥这一架构的能力。

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

按照分层架构设计，我们可以将团队的人员职【转载请注明来源】【原创不易，请尊重版权】责划分为如下：

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

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

上文已经讲过，这里的应用层里面的“应用”【转载请注明来源】转载请注明出处：www.tangshuang.net和我们平常所讲的Application不本文作者：唐霜，转载请注明出处。【版权所有，侵权必究】是一回事，这里的“应用”是将领域扩展为可【版权所有，侵权必究】著作权归作者所有，禁止商业用途转载。完成业务的实现部分。一般而言，我们可以认本文作者：唐霜，转载请注明出处。著作权归作者所有，禁止商业用途转载。为在应用层，主要完成微前端中的子应用的实【访问 www.tangshuang.net 获取更多精彩内容】【未经授权禁止转载】现，一个子应用，实际上需要包含领域模型的【本文受版权保护】著作权归作者所有，禁止商业用途转载。应用、业务组件的开发、路由的安排、页面的本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。撰写等等工作。当然，由于业务逻辑大部分被【本文首发于唐霜的博客】【访问 www.tangshuang.net 获取更多精彩内容】沉淀在领域层，虽然业务模块的开发者应该熟【作者：唐霜】著作权归作者所有，禁止商业用途转载。悉该业务，但是实际上，他更多的是关心如何【关注微信公众号：wwwtangshuangnet】原创内容，盗版必究。将这一业务进行呈现，即完成界面和交互。而著作权归作者所有，禁止商业用途转载。【访问 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味着这部分代码是完全可复用的，是不需要考【版权所有，侵权必究】本文版权归作者所有，未经授权不得转载。虑平台、端的，无论是在PC上还是APP上【转载请注明来源】著作权归作者所有，禁止商业用途转载。，都可以被使用，也不考虑你所使用的视图框转载请注明出处：www.tangshuang.net本文作者：唐霜，转载请注明出处。架，无论在react中还是angular【原创内容，转载请注明出处】【本文首发于唐霜的博客】中，它都可以被使用。有了这一层，我们所设转载请注明出处：www.tangshuang.net【本文受版权保护】计的微前端子应用分团队开发才成为可能，不【本文首发于唐霜的博客】【访问 www.tangshuang.net 获取更多精彩内容】同的团队可以使用不同技术栈去实现自己的业本文版权归作者所有，未经授权不得转载。【未经授权禁止转载】务，但是底下的领域层代码是不挑框架的，因【未经授权禁止转载】著作权归作者所有，禁止商业用途转载。此，在PC上使用angular，在app未经授权，禁止复制转载。【作者：唐霜】使用react native，都是可行的【本文首发于唐霜的博客】【访问 www.tangshuang.net 获取更多精彩内容】。而也正因为领域层囊括了所有的业务逻辑，未经授权，禁止复制转载。【版权所有】唐霜 www.tangshuang.net所以，对于上层的建设，可以更加关注UI，【转载请注明来源】【版权所有，侵权必究】同时确保了业务逻辑的一致性。

业务场景逻辑本文作者：唐霜，转载请注明出处。

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

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

业务功能模块【访问 www.tangshuang.net 获取更多精彩内容】

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

未经授权，禁止复制转载。【关注微信公众号：wwwtangshuangnet】【原创不易，请尊重版权】【本文受版权保护】本文作者：唐霜，转载请注明出处。

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

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

【访问 www.tangshuang.net 获取更多精彩内容】【原创内容，转载请注明出处】本文作者：唐霜，转载请注明出处。

分层架构设计本文作者：唐霜，转载请注明出处。

【作者：唐霜】原创内容，盗版必究。原创内容，盗版必究。【访问 www.tangshuang.net 获取更多精彩内容】【未经授权禁止转载】

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

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

底层框架封装著作权归作者所有，禁止商业用途转载。

【访问 www.tangshuang.net 获取更多精彩内容】【原创不易，请尊重版权】【原创不易，请尊重版权】【本文受版权保护】原创内容，盗版必究。

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

团队规范【版权所有】唐霜 www.tangshuang.net

【原创不易，请尊重版权】未经授权，禁止复制转载。【转载请注明来源】【原创不易，请尊重版权】

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

著作权归作者所有，禁止商业用途转载。【访问 www.tangshuang.net 获取更多精彩内容】【转载请注明来源】本文作者：唐霜，转载请注明出处。

前端DDD的具体实施本文版权归作者所有，未经授权不得转载。

在前端构建领域模型，我们需要考虑的东西其【关注微信公众号：wwwtangshuangnet】【作者：唐霜】实会更多，因为我们不仅要单纯考虑到业务的本文作者：唐霜，转载请注明出处。著作权归作者所有，禁止商业用途转载。硬性逻辑，同时也要考虑前端在交互层次上的【关注微信公众号：wwwtangshuangnet】【作者：唐霜】一些实用性，如果在表达业务上非常优秀，但【本文首发于唐霜的博客】【关注微信公众号：wwwtangshuangnet】是到了具体开发时很难使用的话，也说明我们本文作者：唐霜，转载请注明出处。【关注微信公众号：wwwtangshuangnet】的实践是不足取的。

转载请注明出处：www.tangshuang.net【原创不易，请尊重版权】转载请注明出处：www.tangshuang.net

领域建模【原创内容，转载请注明出处】

本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。【访问 www.tangshuang.net 获取更多精彩内容】

前端如何进行领域建模呢？我认为需要考虑如转载请注明出处：www.tangshuang.net【本文首发于唐霜的博客】下几个方面。

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

首先，我们需要划分领域，划分限界上下文，未经授权，禁止复制转载。【未经授权禁止转载】从而可以从中提炼出我们建模需要建立哪些实【本文首发于唐霜的博客】【未经授权禁止转载】体、服务、事件等等。其次，我们要以实体为本文版权归作者所有，未经授权不得转载。转载请注明出处：www.tangshuang.net核心去逐渐完善我们的领域模型。最后一点，【版权所有，侵权必究】【版权所有，侵权必究】也是非常重要的一点，我们需要考虑到场景。

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

实体建模【原创内容，转载请注明出处】

【原创不易，请尊重版权】转载请注明出处：www.tangshuang.net本文版权归作者所有，未经授权不得转载。【未经授权禁止转载】【本文受版权保护】

我们基于【访问 www.tangshuang.net 获取更多精彩内容】TySheMo【本文受版权保护】进行实体建模，搭建起我们整个应用的骨架著作权归作者所有，禁止商业用途转载。转载请注明出处：www.tangshuang.net。我们已经通过划分，知道我们需要建立哪些【作者：唐霜】【本文首发于唐霜的博客】实体。但是实际上，大部分情况下，实体是嵌【关注微信公众号：wwwtangshuangnet】转载请注明出处：www.tangshuang.net套的，实体之间存在包含/引用关系。例如我【原创内容，转载请注明出处】本文版权归作者所有，未经授权不得转载。们需要建立订单实体，与之关联的还有支付实原创内容，盗版必究。未经授权，禁止复制转载。体、物流实体等等。这些实体，在某些场景下著作权归作者所有，禁止商业用途转载。【未经授权禁止转载】需要关联在一起，有些场景下需要单独拿出来本文版权归作者所有，未经授权不得转载。【访问 www.tangshuang.net 获取更多精彩内容】，在实际场景中，这取决于是否存在某个字段原创内容，盗版必究。【原创内容，转载请注明出处】。组成实体的是该实体的字段。和后端不同，【本文首发于唐霜的博客】【作者：唐霜】我们在前端构建充血模型，单个字段被放在一【版权所有】唐霜 www.tangshuang.net原创内容，盗版必究。个 Meta 模型中，该 Meta 作为转载请注明出处：www.tangshuang.net转载请注明出处：www.tangshuang.net字段信息交给 Model，Model 作转载请注明出处：www.tangshuang.net未经授权，禁止复制转载。为基类，依据 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【本文受版权保护】本文版权归作者所有，未经授权不得转载。mount 基于另外两个字段自动进行计算转载请注明出处：www.tangshuang.net原创内容，盗版必究。。随后，我们创建模型：

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

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

这便是我们订单模型的最基础最原始的形态。【转载请注明来源】本文版权归作者所有，未经授权不得转载。随后，我们会慢慢去丰富这个模型。例如给单原创内容，盗版必究。本文版权归作者所有，未经授权不得转载。价和数量增加校验逻辑：

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

慢慢的，我们会发现，我们的Meta会越来著作权归作者所有，禁止商业用途转载。【未经授权禁止转载】越丰富，随着Meta的丰富，我们的业务也本文作者：唐霜，转载请注明出处。【作者：唐霜】慢慢丰满起来。

【访问 www.tangshuang.net 获取更多精彩内容】转载请注明出处：www.tangshuang.net【关注微信公众号：wwwtangshuangnet】【原创内容，转载请注明出处】【本文首发于唐霜的博客】

【本文首发于唐霜的博客】未经授权，禁止复制转载。本文版权归作者所有，未经授权不得转载。

【本文受版权保护】著作权归作者所有，禁止商业用途转载。【作者：唐霜】【转载请注明来源】著作权归作者所有，禁止商业用途转载。

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

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

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

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

【转载请注明来源】【访问 www.tangshuang.net 获取更多精彩内容】【本文受版权保护】

业务值对象未经授权，禁止复制转载。

【作者：唐霜】【原创内容，转载请注明出处】转载请注明出处：www.tangshuang.net

本文作者：唐霜，转载请注明出处。【作者：唐霜】转载请注明出处：www.tangshuang.net【原创内容，转载请注明出处】

业务工厂【关注微信公众号：wwwtangshuangnet】

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

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

著作权归作者所有，禁止商业用途转载。【关注微信公众号：wwwtangshuangnet】未经授权，禁止复制转载。

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

交互模型【版权所有】唐霜 www.tangshuang.net

当我们进入具体模块的开发时，我们会发现，著作权归作者所有，禁止商业用途转载。原创内容，盗版必究。跨端开发中，界面和交互是不一致的，一致的原创内容，盗版必究。本文作者：唐霜，转载请注明出处。是交互逻辑。例如同样是发起支付页面，PC本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net上和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作为转载请注明出处：www.tangshuang.net【版权所有】唐霜 www.tangshuang.net交互模型类，因为我们将在具体实现时直接e未经授权，禁止复制转载。未经授权，禁止复制转载。xtends它。在交互模型中，我们提供回本文作者：唐霜，转载请注明出处。原创内容，盗版必究。调函数，组织事件流，载入领域模型，并封装【转载请注明来源】【版权所有，侵权必究】为具体的方法（大部分会以handle开头【访问 www.tangshuang.net 获取更多精彩内容】【版权所有，侵权必究】），将某些周期方法（大部分以on开头）预【转载请注明来源】本文作者：唐霜，转载请注明出处。留出来，等待具体平台上实现。

另外，在交互模型这一层，我们可以提供ho转载请注明出处：www.tangshuang.net本文版权归作者所有，未经授权不得转载。oks函数，用于对某些交互和状态进行封装未经授权，禁止复制转载。【访问 www.tangshuang.net 获取更多精彩内容】。

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

未经授权，禁止复制转载。【访问 www.tangshuang.net 获取更多精彩内容】著作权归作者所有，禁止商业用途转载。

用于在多端之间，共享统一的视图描述，例如原创内容，盗版必究。著作权归作者所有，禁止商业用途转载。：

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

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

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

具体界面交互实现【原创内容，转载请注明出处】

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

【作者：唐霜】原创内容，盗版必究。【原创内容，转载请注明出处】

注意点【未经授权禁止转载】

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

未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。原创内容，盗版必究。转载请注明出处：www.tangshuang.net

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

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

基于DDD的投资系统前端架构设计实战【本文首发于唐霜的博客】

转载请注明出处：www.tangshuang.net未经授权，禁止复制转载。【关注微信公众号：wwwtangshuangnet】

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

业务梳理【未经授权禁止转载】

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

首先，我们需要将我们要准备实现的系统的业【关注微信公众号：wwwtangshuangnet】【本文受版权保护】务进行梳理，该系统的愿景是什么，想要为它【原创不易，请尊重版权】本文版权归作者所有，未经授权不得转载。的用户提供什么价值，从哪些方面去体现，将本文作者：唐霜，转载请注明出处。【作者：唐霜】会实现哪些能力，哪些不需要或需要等到未来本文版权归作者所有，未经授权不得转载。【原创内容，转载请注明出处】实现等等。

本文版权归作者所有，未经授权不得转载。本文作者：唐霜，转载请注明出处。原创内容，盗版必究。本文版权归作者所有，未经授权不得转载。

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

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

面对三种类型的投资，我们需要从中挖掘出共转载请注明出处：www.tangshuang.net本文作者：唐霜，转载请注明出处。性和个性，建立我们的投资领域模型。

除了投资，系统还要负责跟进与投资相关的其【本文受版权保护】本文作者：唐霜，转载请注明出处。他工作，例如解决投资审批相关的审批流，解本文作者：唐霜，转载请注明出处。【转载请注明来源】决投后分析的数据看板，解决投资纠纷的条款【访问 www.tangshuang.net 获取更多精彩内容】转载请注明出处：www.tangshuang.net摘要，解决项目成员贡献度的贡献度算法等等转载请注明出处：www.tangshuang.net【版权所有，侵权必究】。

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

【未经授权禁止转载】本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。【原创内容，转载请注明出处】【转载请注明来源】

为了梳理清楚业务，我们需要和业务人员产品【本文首发于唐霜的博客】【关注微信公众号：wwwtangshuangnet】人员一起，通过事件风暴、领域故事等，把我【访问 www.tangshuang.net 获取更多精彩内容】著作权归作者所有，禁止商业用途转载。们系统将要涉及的方面方面先一一列举出来，未经授权，禁止复制转载。未经授权，禁止复制转载。虽然此时还很混乱，但是我们已经确保我们的【未经授权禁止转载】著作权归作者所有，禁止商业用途转载。系统将要有什么，不会有什么。

著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。本文作者：唐霜，转载请注明出处。

限界上下文确定原创内容，盗版必究。

【本文首发于唐霜的博客】本文版权归作者所有，未经授权不得转载。【原创不易，请尊重版权】【作者：唐霜】

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

投资系统限界上下文划分示意图【未经授权禁止转载】

【原创不易，请尊重版权】未经授权，禁止复制转载。转载请注明出处：www.tangshuang.net

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

【关注微信公众号：wwwtangshuangnet】【未经授权禁止转载】原创内容，盗版必究。【访问 www.tangshuang.net 获取更多精彩内容】

原创内容，盗版必究。本文版权归作者所有，未经授权不得转载。【原创内容，转载请注明出处】【访问 www.tangshuang.net 获取更多精彩内容】

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

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

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

接下来就是代码。原创内容，盗版必究。

未经授权，禁止复制转载。【本文首发于唐霜的博客】【原创不易，请尊重版权】著作权归作者所有，禁止商业用途转载。

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

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

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

分层架构设计【本文首发于唐霜的博客】

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

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

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

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

最后，分层架构并不意味着代码是按层来划分原创内容，盗版必究。【本文受版权保护】的。

【原创内容，转载请注明出处】【访问 www.tangshuang.net 获取更多精彩内容】本文作者：唐霜，转载请注明出处。【作者：唐霜】原创内容，盗版必究。

【本文受版权保护】转载请注明出处：www.tangshuang.net转载请注明出处：www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】

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

【访问 www.tangshuang.net 获取更多精彩内容】【访问 www.tangshuang.net 获取更多精彩内容】本文作者：唐霜，转载请注明出处。

原创内容，盗版必究。

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

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

【作者：唐霜】

libs 基础层的一些实现，主要是第三方未经授权，禁止复制转载。本文作者：唐霜，转载请注明出处。的封装和自建的一些工具

【本文首发于唐霜的博客】

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

【作者：唐霜】

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

【本文首发于唐霜的博客】

【访问 www.tangshuang.net 获取更多精彩内容】

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

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

【关注微信公众号：wwwtangshuangnet】

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

原创内容，盗版必究。

【本文首发于唐霜的博客】

hooks 通用的逻辑hooks函数本文作者：唐霜，转载请注明出处。

【原创不易，请尊重版权】

【未经授权禁止转载】

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

【作者：唐霜】

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

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

@implements 不同端的具体实现【转载请注明来源】转载请注明出处：www.tangshuang.net，以孤岛代码形式进行原型链侵入

原创内容，盗版必究。

【本文首发于唐霜的博客】

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

apps 用户界面层的应用【访问 www.tangshuang.net 获取更多精彩内容】

【本文首发于唐霜的博客】

【访问 www.tangshuang.net 获取更多精彩内容】

【关注微信公众号：wwwtangshuangnet】

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

【原创不易，请尊重版权】原创内容，盗版必究。【未经授权禁止转载】

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

未经授权，禁止复制转载。未经授权，禁止复制转载。【访问 www.tangshuang.net 获取更多精彩内容】

未经授权，禁止复制转载。未经授权，禁止复制转载。原创内容，盗版必究。转载请注明出处：www.tangshuang.net本文作者：唐霜，转载请注明出处。

investment-portfolio【访问 www.tangshuang.net 获取更多精彩内容】未经授权，禁止复制转载。
- controllers【关注微信公众号：wwwtangshuangnet】
- views转载请注明出处：www.tangshuang.net
- @platforms 【关注微信公众号：wwwtangshuangnet】
  - pc 原创内容，盗版必究。
    - supply著作权归作者所有，禁止商业用途转载。
    - list【转载请注明来源】
    - append【原创不易，请尊重版权】
    - detail未经授权，禁止复制转载。
  - mobile原创内容，盗版必究。
  - native著作权归作者所有，禁止商业用途转载。
  - wechat【本文受版权保护】

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

【作者：唐霜】

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

在用户界面层apps中，我们每一个应用所【访问 www.tangshuang.net 获取更多精彩内容】【未经授权禁止转载】对应的端可能都不同，例如我们在手机上会有本文作者：唐霜，转载请注明出处。【本文受版权保护】两个app，这两个app我们会用两个目录【访问 www.tangshuang.net 获取更多精彩内容】本文作者：唐霜，转载请注明出处。作为入口，不过等下我们会讲到，它们走相同【未经授权禁止转载】【关注微信公众号：wwwtangshuangnet】的构建工具链。

【访问 www.tangshuang.net 获取更多精彩内容】本文作者：唐霜，转载请注明出处。【未经授权禁止转载】【原创内容，转载请注明出处】

【访问 www.tangshuang.net 获取更多精彩内容】【原创不易，请尊重版权】著作权归作者所有，禁止商业用途转载。

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

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

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

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

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

未经授权，禁止复制转载。【原创内容，转载请注明出处】【访问 www.tangshuang.net 获取更多精彩内容】

结语转载请注明出处：www.tangshuang.net

【访问 www.tangshuang.net 获取更多精彩内容】【原创不易，请尊重版权】【关注微信公众号：wwwtangshuangnet】

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

【原创不易，请尊重版权】【原创不易，请尊重版权】原创内容，盗版必究。

【原创内容，转载请注明出处】本文作者：唐霜，转载请注明出处。【本文首发于唐霜的博客】著作权归作者所有，禁止商业用途转载。【本文首发于唐霜的博客】【转载请注明来源】【转载请注明来源】【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。原创内容，盗版必究。【本文首发于唐霜的博客】原创内容，盗版必究。未经授权，禁止复制转载。本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。转载请注明出处：www.tangshuang.net本文作者：唐霜，转载请注明出处。本文版权归作者所有，未经授权不得转载。【关注微信公众号：wwwtangshuangnet】【版权所有】唐霜 www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】本文版权归作者所有，未经授权不得转载。【本文首发于唐霜的博客】转载请注明出处：www.tangshuang.net本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net转载请注明出处：www.tangshuang.net原创内容，盗版必究。著作权归作者所有，禁止商业用途转载。【本文首发于唐霜的博客】【关注微信公众号：wwwtangshuangnet】本文作者：唐霜，转载请注明出处。【作者：唐霜】转载请注明出处：www.tangshuang.net【版权所有，侵权必究】【本文受版权保护】【原创不易，请尊重版权】【原创内容，转载请注明出处】【本文首发于唐霜的博客】【版权所有，侵权必究】转载请注明出处：www.tangshuang.net【本文受版权保护】【版权所有】唐霜 www.tangshuang.net【未经授权禁止转载】【原创不易，请尊重版权】【原创内容，转载请注明出处】【原创内容，转载请注明出处】原创内容，盗版必究。【未经授权禁止转载】原创内容，盗版必究。【版权所有，侵权必究】【版权所有，侵权必究】本文版权归作者所有，未经授权不得转载。【未经授权禁止转载】原创内容，盗版必究。本文作者：唐霜，转载请注明出处。原创内容，盗版必究。【转载请注明来源】【转载请注明来源】本文版权归作者所有，未经授权不得转载。【关注微信公众号：wwwtangshuangnet】

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

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

DDD知识体系转载请注明出处：www.tangshuang.net

DDD的意义转载请注明出处：www.tangshuang.net

DDD不是什么？转载请注明出处：www.tangshuang.net

DDD中的基本概念【版权所有】唐霜 www.tangshuang.net

统一语言【版权所有】唐霜 www.tangshuang.net

领域模型【未经授权禁止转载】

架构设计【转载请注明来源】

战略设计和战术设计【转载请注明来源】

后端DDD概览未经授权，禁止复制转载。

前端DDD详解未经授权，禁止复制转载。

前端DDD与后端的不同【原创内容，转载请注明出处】

项目工程变更原创内容，盗版必究。

基于微前端的业务模块拆分【关注微信公众号：wwwtangshuangnet】

基于构建工具链的聚合应用和多端分发本文作者：唐霜，转载请注明出处。

团队人员分工与职责变更【本文受版权保护】

代码模型变更【版权所有】唐霜 www.tangshuang.net

领域层代码本文作者：唐霜，转载请注明出处。

业务场景逻辑本文作者：唐霜，转载请注明出处。

业务功能模块【访问 www.tangshuang.net 获取更多精彩内容】

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

分层架构设计本文作者：唐霜，转载请注明出处。

底层框架封装著作权归作者所有，禁止商业用途转载。

团队规范【版权所有】唐霜 www.tangshuang.net

前端DDD的具体实施本文版权归作者所有，未经授权不得转载。

领域建模【原创内容，转载请注明出处】

交互模型【版权所有】唐霜 www.tangshuang.net

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

具体界面交互实现【原创内容，转载请注明出处】

注意点【未经授权禁止转载】

基于DDD的投资系统前端架构设计实战【本文首发于唐霜的博客】

业务梳理【未经授权禁止转载】

限界上下文确定原创内容，盗版必究。

构建领域模型【版权所有】唐霜 www.tangshuang.net

分层架构设计【本文首发于唐霜的博客】

代码模型设计【版权所有，侵权必究】

项目工程设计【版权所有】唐霜 www.tangshuang.net

结语转载请注明出处：www.tangshuang.net