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

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

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

【本文受版权保护】【本文首发于唐霜的博客】【本文受版权保护】【转载请注明来源】

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

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

DDD知识体系

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

【访问 www.tangshuang.net 获取更多精彩内容】【原创不易，请尊重版权】【访问 www.tangshuang.net 获取更多精彩内容】

DDD的意义

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

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

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

未经授权，禁止复制转载。【作者：唐霜】

DDD不是什么？

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

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

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

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

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

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

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

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

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

DDD中的基本概念

统一语言

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

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

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

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

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

领域模型

首先一定要强调，“领域模型”不是代码！不【作者：唐霜】转载请注明出处：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的订单，虽然订单本质上和支付无关，支付只【版权所有】唐霜 www.tangshuang.net【关注微信公众号：wwwtangshuangnet】需要支付方+接收方+中介，但是订单是该支【关注微信公众号：wwwtangshuangnet】【访问 www.tangshuang.net 获取更多精彩内容】付关联的业务；通用域是可能与业务无强相关著作权归作者所有，禁止商业用途转载。【转载请注明来源】单需要作为系统的一部分，例如系统中的登录【转载请注明来源】【本文受版权保护】、用户、权限等等，这些领域在行业有通用解【本文首发于唐霜的博客】【作者：唐霜】决方案，同时在本系统中可能存在某些特殊性本文版权归作者所有，未经授权不得转载。【版权所有】唐霜 www.tangshuang.net，但是它们与我们的核心业务相隔甚远，但又【原创内容，转载请注明出处】【转载请注明来源】必须存在。

限界上下文

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

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

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

在DDD中，界限上下文面临三个问题：如何转载请注明出处：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 获取更多精彩内容】以纵览我们系统中各个子域之间关系的全貌。

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

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

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

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

建模方案

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

DDD通过建模来让领域中的事物、行为、关【作者：唐霜】原创内容，盗版必究。联确定下来，使之固定化，可以作为代码在系【版权所有】唐霜 www.tangshuang.net【原创不易，请尊重版权】统中被使用。它提供了如下几种建模方案：实原创内容，盗版必究。【关注微信公众号：wwwtangshuangnet】体、值对象、聚合和聚合根、服务、工厂、仓未经授权，禁止复制转载。【访问 www.tangshuang.net 获取更多精彩内容】库（资源库）。这部分内容其实与后端结合比转载请注明出处：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【本文首发于唐霜的博客】举出来，我们常常只需要关注那些比较特殊的转载请注明出处：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转载请注明出处：www.tangshuang.net域事件地图，从而让我们有机会去检查，我们【原创内容，转载请注明出处】【转载请注明来源】在业务上的需求，是被代码正确实现了的。

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

架构设计

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

四层架构

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

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

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

六边形架构

也被称为端口与适配器架构，这种架构在洋葱【原创不易，请尊重版权】未经授权，禁止复制转载。架构基础上，增加了端口和适配器，每一条边本文版权归作者所有，未经授权不得转载。【关注微信公众号：wwwtangshuangnet】代表不同类型的短裤，端口要么处理输入，要转载请注明出处：www.tangshuang.net【原创内容，转载请注明出处】么处理输出，每种外界类型，都有一个适配器【本文首发于唐霜的博客】【未经授权禁止转载】与之匹配，外界通过接口与内部交互。

虽然三种架构形式上不同，但是它们的本质相【本文首发于唐霜的博客】【转载请注明来源】差无几，即都是以领域模型为中心，构建业务【本文受版权保护】著作权归作者所有，禁止商业用途转载。的核心逻辑。

战略设计和战术设计

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

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

后端DDD概览

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

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

基于DDD的方法论，我们一般的工作顺序是未经授权，禁止复制转载。【转载请注明来源】：产品愿景、业务场景分析、领域建模、微服【本文受版权保护】【本文首发于唐霜的博客】务拆分；架构落地、代码模型、工程搭建。

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

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

前端DDD详解

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

前端DDD与后端的不同

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

项目工程变更

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

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

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

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

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

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

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

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

团队人员分工与职责变更

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

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

按照分层架构设计，我们可以将团队的人员职【本文受版权保护】【原创内容，转载请注明出处】责划分为如下：

转载请注明出处：www.tangshuang.net【转载请注明来源】【本文首发于唐霜的博客】【本文受版权保护】

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

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

业务场景逻辑

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

转载请注明出处：www.tangshuang.net【作者：唐霜】【本文受版权保护】

业务功能模块

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

扩展能力

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

分层架构设计

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

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

底层框架封装

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

团队规范

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

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

前端DDD的具体实施

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

领域建模

前端如何进行领域建模呢？我认为需要考虑如【转载请注明来源】【关注微信公众号：wwwtangshuangnet】下几个方面。

【关注微信公众号：wwwtangshuangnet】【原创不易，请尊重版权】

首先，我们需要划分领域，划分限界上下文，转载请注明出处：www.tangshuang.net本文版权归作者所有，未经授权不得转载。从而可以从中提炼出我们建模需要建立哪些实本文版权归作者所有，未经授权不得转载。【版权所有】唐霜 www.tangshuang.net体、服务、事件等等。其次，我们要以实体为本文版权归作者所有，未经授权不得转载。【本文受版权保护】核心去逐渐完善我们的领域模型。最后一点，【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。也是非常重要的一点，我们需要考虑到场景。

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

实体建模

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

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

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

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

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

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

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

慢慢的，我们会发现，我们的Meta会越来【转载请注明来源】著作权归作者所有，禁止商业用途转载。越丰富，随着Meta的丰富，我们的业务也【原创不易，请尊重版权】著作权归作者所有，禁止商业用途转载。慢慢丰满起来。

服务

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

数据服务

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

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

事件服务

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

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

业务值对象

其实在前端比较少有值对象，我们大部分情况【转载请注明来源】未经授权，禁止复制转载。下会从后端拉取必要的列表，例如行业、地区【转载请注明来源】转载请注明出处：www.tangshuang.net、阶段等等。

业务工厂

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

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

未经授权，禁止复制转载。【本文首发于唐霜的博客】著作权归作者所有，禁止商业用途转载。【原创内容，转载请注明出处】

业务聚合

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

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

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

交互模型

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

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

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【版权所有】唐霜 www.tangshuang.net未经授权，禁止复制转载。xtends它。在交互模型中，我们提供回【作者：唐霜】著作权归作者所有，禁止商业用途转载。调函数，组织事件流，载入领域模型，并封装【未经授权禁止转载】【版权所有】唐霜 www.tangshuang.net为具体的方法（大部分会以handle开头转载请注明出处：www.tangshuang.net转载请注明出处：www.tangshuang.net），将某些周期方法（大部分以on开头）预原创内容，盗版必究。著作权归作者所有，禁止商业用途转载。留出来，等待具体平台上实现。

【访问 www.tangshuang.net 获取更多精彩内容】【访问 www.tangshuang.net 获取更多精彩内容】【转载请注明来源】

另外，在交互模型这一层，我们可以提供ho本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。oks函数，用于对某些交互和状态进行封装【作者：唐霜】原创内容，盗版必究。。

抽象视图

用于在多端之间，共享统一的视图描述，例如本文版权归作者所有，未经授权不得转载。【访问 www.tangshuang.net 获取更多精彩内容】：

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

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

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

具体界面交互实现

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

【本文受版权保护】【原创不易，请尊重版权】

注意点

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

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

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

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

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

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

业务梳理

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

对于投资这件事而言，有非常大的学问，但对【本文首发于唐霜的博客】著作权归作者所有，禁止商业用途转载。于一个管理系统而言，我们需要知道，我们要【本文受版权保护】【原创不易，请尊重版权】面对的是三大类的投资：一级市场投资、二级著作权归作者所有，禁止商业用途转载。未经授权，禁止复制转载。市场投资、基金投资。其中一级市场投资最复【访问 www.tangshuang.net 获取更多精彩内容】【访问 www.tangshuang.net 获取更多精彩内容】杂，从市场中发现一家有价值的公司，到与【原创内容，转载请注明出处】本文作者：唐霜，转载请注明出处。该公司调查，内部讨论，TS，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 获取更多精彩内容】性，又是很复杂的特殊性。基金投资则主要是【本文首发于唐霜的博客】【作者：唐霜】针对投资一级市场的基金（Fund of 【本文受版权保护】【原创不易，请尊重版权】Fund），要考虑GP、LP，是否采用S【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。PV架构，投资过程中被投基金所投资的公司【本文受版权保护】【原创不易，请尊重版权】是否与我已投的公司存在重叠，等等问题。

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

面对三种类型的投资，我们需要从中挖掘出共【本文受版权保护】【本文首发于唐霜的博客】性和个性，建立我们的投资领域模型。

【本文受版权保护】转载请注明出处：www.tangshuang.net转载请注明出处：www.tangshuang.net

为了梳理清楚业务，我们需要和业务人员产品本文作者：唐霜，转载请注明出处。本文作者：唐霜，转载请注明出处。人员一起，通过事件风暴、领域故事等，把我【版权所有】唐霜 www.tangshuang.net原创内容，盗版必究。们系统将要涉及的方面方面先一一列举出来，【原创内容，转载请注明出处】著作权归作者所有，禁止商业用途转载。虽然此时还很混乱，但是我们已经确保我们的【未经授权禁止转载】【未经授权禁止转载】系统将要有什么，不会有什么。

限界上下文确定

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

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

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

上图只是一个举例，在真实的系统设计中，我【关注微信公众号：wwwtangshuangnet】【本文首发于唐霜的博客】们实际上会有更多领域更多上下文，这里也只【关注微信公众号：wwwtangshuangnet】【关注微信公众号：wwwtangshuangnet】列举了业务关联部分，实际上，我们还有更多【访问 www.tangshuang.net 获取更多精彩内容】【访问 www.tangshuang.net 获取更多精彩内容】支撑域和通用域，这些都没有展示出来。

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

完成划分之后，我们要找出限界上下文之间的【作者：唐霜】【原创内容，转载请注明出处】映射，实际上，这种映射是非常容易的，只不转载请注明出处：www.tangshuang.net【本文首发于唐霜的博客】过有的时候我们不能忽略细节。

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

我们通过限界上下文映射，梳理出了系统中各著作权归作者所有，禁止商业用途转载。【未经授权禁止转载】个上下文之间的关系，这些关系形成一个完整【原创不易，请尊重版权】原创内容，盗版必究。的网络，在后续代码开发中，会为我们提供各【本文受版权保护】【未经授权禁止转载】种依赖关系的依据。

【访问 www.tangshuang.net 获取更多精彩内容】【作者：唐霜】

构建领域模型

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

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

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

接下来就是代码。

【访问 www.tangshuang.net 获取更多精彩内容】【原创不易，请尊重版权】转载请注明出处：www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】

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

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

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

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

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

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

分层架构设计

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

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

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

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

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

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

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

最后，分层架构并不意味着代码是按层来划分转载请注明出处：www.tangshuang.net转载请注明出处：www.tangshuang.net的。

代码模型设计

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

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

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

【转载请注明来源】

libs 基础层的一些实现，主要是第三方【访问 www.tangshuang.net 获取更多精彩内容】未经授权，禁止复制转载。的封装和自建的一些工具

【作者：唐霜】

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

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

subjects 按照大的领域概念进行划【作者：唐霜】本文作者：唐霜，转载请注明出处。分后的领域，包括核心域、支撑域和通用域的本文版权归作者所有，未经授权不得转载。本文作者：唐霜，转载请注明出处。全部

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

原创内容，盗版必究。

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

components 基础层的逻辑组件，本文版权归作者所有，未经授权不得转载。未经授权，禁止复制转载。以及UI组件的抽象（UI组件需要依赖不同【访问 www.tangshuang.net 获取更多精彩内容】【本文首发于唐霜的博客】端，其实现在各自端实现）

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

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

【未经授权禁止转载】

原创内容，盗版必究。

hooks 通用的逻辑hooks函数

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

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

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

【本文受版权保护】

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

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

@implements 不同端的具体实现【作者：唐霜】未经授权，禁止复制转载。，以孤岛代码形式进行原型链侵入

【未经授权禁止转载】

【转载请注明来源】

apps 用户界面层的应用

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

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

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

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

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

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

【访问 www.tangshuang.net 获取更多精彩内容】【访问 www.tangshuang.net 获取更多精彩内容】【本文受版权保护】【本文受版权保护】

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

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

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

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

【作者：唐霜】

首先是要分端，因为不同端端实现是不同的，【原创不易，请尊重版权】本文作者：唐霜，转载请注明出处。特别是native和wechat的实现，【本文受版权保护】【未经授权禁止转载】与web的实现差距比较大。

【本文首发于唐霜的博客】【关注微信公众号：wwwtangshuangnet】原创内容，盗版必究。

【本文首发于唐霜的博客】【关注微信公众号：wwwtangshuangnet】本文作者：唐霜，转载请注明出处。【转载请注明来源】

项目工程设计

【作者：唐霜】【作者：唐霜】

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

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

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

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

【本文受版权保护】原创内容，盗版必究。

结语

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

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

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

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

DDD知识体系

DDD的意义

DDD不是什么？

DDD中的基本概念

统一语言

领域模型

架构设计

战略设计和战术设计

后端DDD概览

前端DDD详解

前端DDD与后端的不同

项目工程变更

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

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

团队人员分工与职责变更

代码模型变更

领域层代码

业务场景逻辑

业务功能模块

扩展能力

分层架构设计

底层框架封装

团队规范

前端DDD的具体实施

领域建模

交互模型

抽象视图

具体界面交互实现

注意点

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

业务梳理

限界上下文确定

构建领域模型

分层架构设计

代码模型设计

项目工程设计

结语