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

【作者：唐霜】【本文受版权保护】【转载请注明来源】【未经授权禁止转载】【未经授权禁止转载】

本文的所有内容我梳理为一张思维导图，你可转载请注明出处：www.tangshuang.net著作权归作者所有，禁止商业用途转载。以根据这张图，获得大致的内容框架。

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

DDD知识体系【本文首发于唐霜的博客】

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

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

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

DDD的意义【本文受版权保护】

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

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

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

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

【关注微信公众号：wwwtangshuangnet】【未经授权禁止转载】原创内容，盗版必究。

DDD不是什么？【版权所有】唐霜 www.tangshuang.net

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

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

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

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

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

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

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

DDD中的基本概念本文作者：唐霜，转载请注明出处。

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

统一语言【原创不易，请尊重版权】

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

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

转载请注明出处：www.tangshuang.net转载请注明出处：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【转载请注明来源】一模块上。复杂的业务上下文对于新成员而言【转载请注明来源】【原创内容，转载请注明出处】，需要有一个学习的时间，而如果有统一语言未经授权，禁止复制转载。【关注微信公众号：wwwtangshuangnet】的沉淀，则可以帮助这些新成员快速了解。

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

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

领域模型【本文受版权保护】

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

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

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

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

一个系统中，一个领域可以分为多个子域，子【本文首发于唐霜的博客】著作权归作者所有，禁止商业用途转载。域还能分为多个子域。

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

领域的分类著作权归作者所有，禁止商业用途转载。

【原创不易，请尊重版权】【关注微信公众号：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必须存在。

【作者：唐霜】【转载请注明来源】【原创不易，请尊重版权】著作权归作者所有，禁止商业用途转载。

限界上下文【原创内容，转载请注明出处】

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

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

在DDD中，界限上下文面临三个问题：如何本文版权归作者所有，未经授权不得转载。【本文首发于唐霜的博客】划分？怎么映射？怎样防腐？

转载请注明出处：www.tangshuang.net本文作者：唐霜，转载请注明出处。【原创内容，转载请注明出处】【关注微信公众号：wwwtangshuangnet】【转载请注明来源】

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

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

限界上下文的映射，就是将被划分好的不同限【本文首发于唐霜的博客】【原创内容，转载请注明出处】界上下文之间的关联标注出来，同时还要标注【转载请注明来源】本文作者：唐霜，转载请注明出处。出它们之间的依赖关系。有了映射，我们就可原创内容，盗版必究。原创内容，盗版必究。以纵览我们系统中各个子域之间关系的全貌。

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

U到D是影响作用方向，D到U是依赖方向转载请注明出处：www.tangshuang.net

著作权归作者所有，禁止商业用途转载。原创内容，盗版必究。【转载请注明来源】转载请注明出处：www.tangshuang.net

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

【转载请注明来源】【原创不易，请尊重版权】【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。

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

DDD通过建模来让领域中的事物、行为、关【版权所有】唐霜 www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】联确定下来，使之固定化，可以作为代码在系转载请注明出处：www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】统中被使用。它提供了如下几种建模方案：实【版权所有，侵权必究】【未经授权禁止转载】体、值对象、聚合和聚合根、服务、工厂、仓【版权所有，侵权必究】【转载请注明来源】库（资源库）。这部分内容其实与后端结合比本文版权归作者所有，未经授权不得转载。转载请注明出处：www.tangshuang.net较紧密，前端开发人员往往无法理解。而且D【本文受版权保护】未经授权，禁止复制转载。DD的方法是面向对象的建模方法，这与前端本文版权归作者所有，未经授权不得转载。未经授权，禁止复制转载。盛行的函数式编程志道不同，但我个人而言，【原创内容，转载请注明出处】【关注微信公众号：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 获取更多精彩内容】未经授权，禁止复制转载。况，“当……时”即一个事件。但在构建领域本文版权归作者所有，未经授权不得转载。【本文受版权保护】模型时，我们并非需要把所有的领域事件都列本文版权归作者所有，未经授权不得转载。【转载请注明来源】举出来，我们常常只需要关注那些比较特殊的【本文受版权保护】原创内容，盗版必究。事件，即那种可能存在跨子域操作的事件。例【关注微信公众号：wwwtangshuangnet】【版权所有，侵权必究】如，“当支付完成时，订单进入配送阶段”，【转载请注明来源】【访问 www.tangshuang.net 获取更多精彩内容】其中“当支付完成”这个事件往往发生在支付【原创内容，转载请注明出处】原创内容，盗版必究。领域，而“订单进入配送阶段”则是对订单领未经授权，禁止复制转载。【关注微信公众号：wwwtangshuangnet】域的操作，如果强行在支付领域中调用订单领【本文受版权保护】【版权所有】唐霜 www.tangshuang.net域的方法，则可能导致订单领域不得不考虑提【访问 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 获取更多精彩内容】原创内容，盗版必究。的封装。之所以出现这种情况，是因为基于事【本文首发于唐霜的博客】【关注微信公众号：wwwtangshuangnet】件中心的逻辑流程实际上代码会比较割裂，单本文作者：唐霜，转载请注明出处。【原创内容，转载请注明出处】纯从代码上看，我们不知道这个事件是在哪里【未经授权禁止转载】未经授权，禁止复制转载。被触发的，或者我们不知道这个事件有没有正【转载请注明来源】【访问 www.tangshuang.net 获取更多精彩内容】确被订阅。因此，在实际工作中，我们需要在未经授权，禁止复制转载。未经授权，禁止复制转载。领域建模时，勾勒出领域事件的全貌，画出领转载请注明出处：www.tangshuang.net转载请注明出处：www.tangshuang.net域事件地图，从而让我们有机会去检查，我们本文作者：唐霜，转载请注明出处。【转载请注明来源】在业务上的需求，是被代码正确实现了的。

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

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

【关注微信公众号：wwwtangshuangnet】【本文受版权保护】【原创不易，请尊重版权】【未经授权禁止转载】【转载请注明来源】

DDD作为技术方法论，在架构设计上提供了【关注微信公众号：wwwtangshuangnet】【转载请注明来源】自己的观点。应用构建过程中，我们首先是以转载请注明出处：www.tangshuang.net【原创内容，转载请注明出处】领域为中心，围绕领域去构建应用的。但同时【本文首发于唐霜的博客】【本文首发于唐霜的博客】我们要考虑在实际实现过程中，技术上往往会本文版权归作者所有，未经授权不得转载。本文作者：唐霜，转载请注明出处。有一些局限，因此，我们不可能以完全理想化【作者：唐霜】【访问 www.tangshuang.net 获取更多精彩内容】的方式构建我们的应用，因此，DDD并不提【访问 www.tangshuang.net 获取更多精彩内容】【本文首发于唐霜的博客】供具体的架构方案，而是提供设计思路。

四层架构【转载请注明来源】

将我们的整个应用自底向顶分为“基础设施层未经授权，禁止复制转载。【转载请注明来源】->领域层->应用层->本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net;用户界面层”，由于DDD的首创主要是面转载请注明出处：www.tangshuang.net本文版权归作者所有，未经授权不得转载。向后端，因此其中的“应用层”更多的是站在【未经授权禁止转载】【原创内容，转载请注明出处】后端的角度去看待后端应用的实现，更多强调本文作者：唐霜，转载请注明出处。【未经授权禁止转载】数据的存取和数据流，中间还要考虑后端软硬本文版权归作者所有，未经授权不得转载。【版权所有，侵权必究】环境和各类服务的协调。而在前端，则可能不【关注微信公众号：wwwtangshuangnet】【原创内容，转载请注明出处】同，我们可能更多会去看某一业务的具体实现本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。，例如我们知道有支付这个领域对象，但是，【作者：唐霜】著作权归作者所有，禁止商业用途转载。在前端应用中，我们需要为支付的创建、查看【版权所有】唐霜 www.tangshuang.net【本文首发于唐霜的博客】、转账等等去进行处理，因此，在领域层和用【版权所有】唐霜 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节奏进行接下来的工作，有哪些需要其他解决【转载请注明来源】【本文受版权保护】的问题。而战术设计则是具体实现某个目标的转载请注明出处：www.tangshuang.net未经授权，禁止复制转载。方法，通过事件风暴、用例分析、四色建模、原创内容，盗版必究。【版权所有】唐霜 www.tangshuang.net领域故事讲述等等，其中前文讲的建模方案、【关注微信公众号：wwwtangshuangnet】本文作者：唐霜，转载请注明出处。架构设计也包含在内。

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

后端DDD概览【访问 www.tangshuang.net 获取更多精彩内容】

【未经授权禁止转载】著作权归作者所有，禁止商业用途转载。本文作者：唐霜，转载请注明出处。本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net

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

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

基于DDD的方法论，我们一般的工作顺序是转载请注明出处：www.tangshuang.net【原创内容，转载请注明出处】：产品愿景、业务场景分析、领域建模、微服本文版权归作者所有，未经授权不得转载。转载请注明出处：www.tangshuang.net务拆分；架构落地、代码模型、工程搭建。

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

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

著作权归作者所有，禁止商业用途转载。【未经授权禁止转载】【本文首发于唐霜的博客】

前端DDD详解【版权所有，侵权必究】

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

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

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

前端DDD与后端的不同著作权归作者所有，禁止商业用途转载。

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

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

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

项目工程变更【原创不易，请尊重版权】

要再前端实施DDD，我们的前端项目工程将【版权所有】唐霜 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 获取更多精彩内容】部的模块。基于微前端的理念，我们可以构建本文版权归作者所有，未经授权不得转载。【转载请注明来源】出呈现单一业务的子应用，该子应用内部可以本文版权归作者所有，未经授权不得转载。原创内容，盗版必究。完成业务逻辑、界面呈现、交互过程的全部，【本文首发于唐霜的博客】【版权所有】唐霜 www.tangshuang.net同时，基于防腐层或端口抑或领域事件，在子【版权所有，侵权必究】转载请注明出处：www.tangshuang.net应用之间所带来的副作用影响到其他子应用中未经授权，禁止复制转载。本文版权归作者所有，未经授权不得转载。。在这个过程中，我个人的经验里，有一个非【本文受版权保护】【转载请注明来源】常重要的点，就是路由。对于单一业务模块而本文版权归作者所有，未经授权不得转载。【关注微信公众号：wwwtangshuangnet】言，往往不止一个页面，需要通过路由进行展【版权所有】唐霜 www.tangshuang.net【版权所有】唐霜 www.tangshuang.net现的控制。我在Nautil本文版权归作者所有，未经授权不得转载。中设计了分布式的路由，可以让独立的子应用【访问 www.tangshuang.net 获取更多精彩内容】【原创内容，转载请注明出处】拥有自己的路由，而放到整个应用中时，不影【版权所有，侵权必究】转载请注明出处：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际上，它们底下，是聚合了对应业务的相同模【作者：唐霜】【原创不易，请尊重版权】块，再底层则是相同的领域模型。

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

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

团队人员分工与职责变更【关注微信公众号：wwwtangshuangnet】

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

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

按照分层架构设计，我们可以将团队的人员职本文版权归作者所有，未经授权不得转载。【原创内容，转载请注明出处】责划分为如下：

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

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

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

代码模型变更【转载请注明来源】

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

【关注微信公众号：wwwtangshuangnet】【访问 www.tangshuang.net 获取更多精彩内容】【转载请注明来源】

领域层代码【转载请注明来源】

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

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

业务场景逻辑本文版权归作者所有，未经授权不得转载。

原创内容，盗版必究。【原创内容，转载请注明出处】原创内容，盗版必究。【关注微信公众号：wwwtangshuangnet】

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

业务功能模块【版权所有】唐霜 www.tangshuang.net

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

即等价于微前端子应用，在领域层基础上，结本文作者：唐霜，转载请注明出处。【访问 www.tangshuang.net 获取更多精彩内容】合业务场景，构建出某一具体业务的完整界面本文版权归作者所有，未经授权不得转载。【未经授权禁止转载】交互。

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

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

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

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

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

底层框架封装【作者：唐霜】

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

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

【本文受版权保护】【转载请注明来源】【未经授权禁止转载】转载请注明出处：www.tangshuang.net【关注微信公众号：wwwtangshuangnet】

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

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

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

前端DDD的具体实施本文作者：唐霜，转载请注明出处。

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

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

领域建模【原创不易，请尊重版权】

【本文首发于唐霜的博客】转载请注明出处：www.tangshuang.net转载请注明出处：www.tangshuang.net

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

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

【本文首发于唐霜的博客】【本文受版权保护】【原创内容，转载请注明出处】【关注微信公众号：wwwtangshuangnet】

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

【作者：唐霜】未经授权，禁止复制转载。未经授权，禁止复制转载。【关注微信公众号：wwwtangshuangnet】

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

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

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
  },
})

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会越来著作权归作者所有，禁止商业用途转载。【关注微信公众号：wwwtangshuangnet】越丰富，随着Meta的丰富，我们的业务也转载请注明出处：www.tangshuang.net本文版权归作者所有，未经授权不得转载。慢慢丰满起来。

服务【原创内容，转载请注明出处】

服务可以理解为工厂，我们将Service【原创不易，请尊重版权】【未经授权禁止转载】设计为单例模式，在应用中，一个服务，应该【本文受版权保护】【本文首发于唐霜的博客】只使用该单例，从而确保行为的一致性。

原创内容，盗版必究。【转载请注明来源】【本文首发于唐霜的博客】

数据服务【本文受版权保护】

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

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

事件服务【转载请注明来源】

和数据服务一样，我们往往需要在整个模块内原创内容，盗版必究。【作者：唐霜】，甚至应用层面，使用事件，事件被具体模块【本文首发于唐霜的博客】著作权归作者所有，禁止商业用途转载。引用，进行订阅或发布，这完全由我们前面提本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。到的事件图来决定。这里比较麻烦的是事件名【原创内容，转载请注明出处】【本文首发于唐霜的博客】的确定，因为如果我们自己确定事件名，会导【原创不易，请尊重版权】转载请注明出处：www.tangshuang.net致可能两个地方使用了相同事件名而引起冲突著作权归作者所有，禁止商业用途转载。转载请注明出处：www.tangshuang.net。解决办法是我们直接在EventServ【版权所有】唐霜 www.tangshuang.net未经授权，禁止复制转载。ice上声明事件枚举（enum），在使用本文作者：唐霜，转载请注明出处。【作者：唐霜】事件名时，只能使用该枚举内的名称，这可以【版权所有，侵权必究】本文作者：唐霜，转载请注明出处。通过typescript来做好约束。这样【版权所有】唐霜 www.tangshuang.net【版权所有】唐霜 www.tangshuang.net我们就可以避免在一个EventServi【原创不易，请尊重版权】【转载请注明来源】ce中写出相同的事件名，同时，其他模块使本文版权归作者所有，未经授权不得转载。【访问 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数、服务操作聚合、实体，是指同一层面，但【本文受版权保护】【本文受版权保护】实际上在单一聚合内，我们往往把这些工厂、本文作者：唐霜，转载请注明出处。【原创内容，转载请注明出处】服务、实体全都囊括在内，形成一个业务的闭本文版权归作者所有，未经授权不得转载。【未经授权禁止转载】环。聚合向外提供接口，用于调用这些封装，【原创内容，转载请注明出处】【原创不易，请尊重版权】从而实现实体状态的流转。聚合是业务对象、原创内容，盗版必究。【原创内容，转载请注明出处】业务逻辑的统一出口，也是可以实现跨站跨端著作权归作者所有，禁止商业用途转载。著作权归作者所有，禁止商业用途转载。复用的关键。在 Nautil 中，聚合用【未经授权禁止转载】著作权归作者所有，禁止商业用途转载。 Controller 来表达，一个 C【转载请注明来源】【作者：唐霜】ontroller 提供了该业务的聚合。

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

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

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

另外，在交互模型这一层，我们可以提供ho【原创不易，请尊重版权】【访问 www.tangshuang.net 获取更多精彩内容】oks函数，用于对某些交互和状态进行封装本文作者：唐霜，转载请注明出处。【转载请注明来源】。

【本文受版权保护】【本文首发于唐霜的博客】【关注微信公众号：wwwtangshuangnet】【原创内容，转载请注明出处】本文作者：唐霜，转载请注明出处。

抽象视图【本文首发于唐霜的博客】

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

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

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

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

具体界面交互实现未经授权，禁止复制转载。

转载请注明出处：www.tangshuang.net【原创不易，请尊重版权】【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。【原创内容，转载请注明出处】

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

注意点转载请注明出处：www.tangshuang.net

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

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

【本文受版权保护】原创内容，盗版必究。原创内容，盗版必究。【原创不易，请尊重版权】

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

基于DDD的投资系统前端架构设计实战【原创内容，转载请注明出处】

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

投资系统是面向投资活动参与者的管理系统，【版权所有】唐霜 www.tangshuang.net未经授权，禁止复制转载。由于业务复杂，参与的人员角色众多，因此，转载请注明出处：www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】是一种需要花很多精力去构建的系统。接下来本文版权归作者所有，未经授权不得转载。【本文受版权保护】我们就用DDD的方法论，来分析我们应该如【未经授权禁止转载】本文作者：唐霜，转载请注明出处。何去设计投资系统的前端架构。

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

【作者：唐霜】【未经授权禁止转载】【作者：唐霜】【关注微信公众号：wwwtangshuangnet】

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

【原创不易，请尊重版权】【关注微信公众号：wwwtangshuangnet】未经授权，禁止复制转载。【关注微信公众号：wwwtangshuangnet】

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

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

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

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

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

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

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

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

接下来就是代码。未经授权，禁止复制转载。

【未经授权禁止转载】转载请注明出处：www.tangshuang.net【作者：唐霜】

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

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

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

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

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

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

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

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

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

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

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

最后，分层架构并不意味着代码是按层来划分原创内容，盗版必究。原创内容，盗版必究。的。

代码模型设计本文版权归作者所有，未经授权不得转载。

原创内容，盗版必究。【本文受版权保护】【关注微信公众号：wwwtangshuangnet】【未经授权禁止转载】

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

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

core 用于提供最底层响应式编程驱动的原创内容，盗版必究。【本文受版权保护】框架实现，需要提供建模、路由、多端同构等原创内容，盗版必究。【本文受版权保护】一系列系统能力的最底层代码

原创内容，盗版必究。

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

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

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

libs 基础层的一些实现，主要是第三方本文作者：唐霜，转载请注明出处。原创内容，盗版必究。的封装和自建的一些工具

【原创内容，转载请注明出处】

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

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

subjects 按照大的领域概念进行划原创内容，盗版必究。【关注微信公众号：wwwtangshuangnet】分后的领域，包括核心域、支撑域和通用域的【本文首发于唐霜的博客】【关注微信公众号：wwwtangshuangnet】全部

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

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

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

【关注微信公众号：wwwtangshuangnet】

components 基础层的逻辑组件，转载请注明出处：www.tangshuang.net【转载请注明来源】以及UI组件的抽象（UI组件需要依赖不同未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。端，其实现在各自端实现）

【原创内容，转载请注明出处】

【转载请注明来源】

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

hooks 通用的逻辑hooks函数【访问 www.tangshuang.net 获取更多精彩内容】

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

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

【转载请注明来源】

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

原创内容，盗版必究。

【本文受版权保护】

@implements 不同端的具体实现【本文受版权保护】本文版权归作者所有，未经授权不得转载。，以孤岛代码形式进行原型链侵入

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

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

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

【未经授权禁止转载】

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

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

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

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

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

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

modules 目录则主要是根据具体场景【未经授权禁止转载】【转载请注明来源】来构筑业务模块，我一般的设计如下：

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

investment-portfolio【本文受版权保护】【未经授权禁止转载】
- controllers【版权所有】唐霜 www.tangshuang.net
- views【关注微信公众号：wwwtangshuangnet】
- @platforms 【本文首发于唐霜的博客】
  - pc 【关注微信公众号：wwwtangshuangnet】
    - supply本文作者：唐霜，转载请注明出处。
    - list【本文受版权保护】
    - append著作权归作者所有，禁止商业用途转载。
    - detail【版权所有，侵权必究】
  - mobile著作权归作者所有，禁止商业用途转载。
  - native【版权所有，侵权必究】
  - wechat【版权所有，侵权必究】

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

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

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

首先是要分端，因为不同端端实现是不同的，【原创不易，请尊重版权】本文版权归作者所有，未经授权不得转载。特别是native和wechat的实现，【本文首发于唐霜的博客】【关注微信公众号：wwwtangshuangnet】与web的实现差距比较大。

在用户界面层apps中，我们每一个应用所【访问 www.tangshuang.net 获取更多精彩内容】未经授权，禁止复制转载。对应的端可能都不同，例如我们在手机上会有【作者：唐霜】【原创内容，转载请注明出处】两个app，这两个app我们会用两个目录转载请注明出处：www.tangshuang.net【本文首发于唐霜的博客】作为入口，不过等下我们会讲到，它们走相同著作权归作者所有，禁止商业用途转载。原创内容，盗版必究。的构建工具链。

项目工程设计【访问 www.tangshuang.net 获取更多精彩内容】

在《复杂企业应用前端架构探索》一文中，我原创内容，盗版必究。本文作者：唐霜，转载请注明出处。详细阐述了项目工程的洋葱图，如下。我们将【未经授权禁止转载】未经授权，禁止复制转载。进入到最外层“前端工程”的探讨。我们要做本文作者：唐霜，转载请注明出处。【原创内容，转载请注明出处】更多的建设，来支持我们多端同构的能力。

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

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

结语【转载请注明来源】

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

本文详细阐述了我在前端运用DDD理念进行未经授权，禁止复制转载。未经授权，禁止复制转载。设计和实战的全部，相信你读毕能形成一个基【版权所有】唐霜 www.tangshuang.net本文版权归作者所有，未经授权不得转载。本的轮廓，知道在前端去实践DDD可能需要著作权归作者所有，禁止商业用途转载。【关注微信公众号：wwwtangshuangnet】经历哪些过程，只是在具体实践过程中，还要【版权所有】唐霜 www.tangshuang.net未经授权，禁止复制转载。去思考具体细节应该怎么做。但是，还是回到【作者：唐霜】【版权所有】唐霜 www.tangshuang.net文章开头所讲，DDD是方法论，而非架构或【原创内容，转载请注明出处】【原创不易，请尊重版权】技术解决方案，可以说DDD几乎没有解决任原创内容，盗版必究。【访问 www.tangshuang.net 获取更多精彩内容】何技术问题。基于DDD去思考和设计我们的【作者：唐霜】【访问 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等等。最后的最后，前端的DDD实践与后端本文版权归作者所有，未经授权不得转载。【版权所有】唐霜 www.tangshuang.net的必然存在不同，这是由技术环境所决定的，【版权所有】唐霜 www.tangshuang.net【本文受版权保护】不可以套用，当我们受到质疑时，应该坚持自【版权所有】唐霜 www.tangshuang.net【本文受版权保护】己的理解。<完>

【原创内容，转载请注明出处】【原创内容，转载请注明出处】【原创内容，转载请注明出处】

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

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

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

DDD知识体系【本文首发于唐霜的博客】

DDD的意义【本文受版权保护】

DDD不是什么？【版权所有】唐霜 www.tangshuang.net

DDD中的基本概念本文作者：唐霜，转载请注明出处。

统一语言【原创不易，请尊重版权】

领域模型【本文受版权保护】

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

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

后端DDD概览【访问 www.tangshuang.net 获取更多精彩内容】

前端DDD详解【版权所有，侵权必究】

前端DDD与后端的不同著作权归作者所有，禁止商业用途转载。

项目工程变更【原创不易，请尊重版权】

基于微前端的业务模块拆分原创内容，盗版必究。

基于构建工具链的聚合应用和多端分发【原创内容，转载请注明出处】

团队人员分工与职责变更【关注微信公众号：wwwtangshuangnet】

代码模型变更【转载请注明来源】

领域层代码【转载请注明来源】

业务场景逻辑本文版权归作者所有，未经授权不得转载。

业务功能模块【版权所有】唐霜 www.tangshuang.net

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

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

底层框架封装【作者：唐霜】

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

前端DDD的具体实施本文作者：唐霜，转载请注明出处。

领域建模【原创不易，请尊重版权】

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

抽象视图【本文首发于唐霜的博客】

具体界面交互实现未经授权，禁止复制转载。

注意点转载请注明出处：www.tangshuang.net

基于DDD的投资系统前端架构设计实战【原创内容，转载请注明出处】

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

限界上下文确定【版权所有，侵权必究】

构建领域模型著作权归作者所有，禁止商业用途转载。

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

代码模型设计本文版权归作者所有，未经授权不得转载。

项目工程设计【访问 www.tangshuang.net 获取更多精彩内容】

结语【转载请注明来源】