我在以往的文章中讨论前端实施基于DDD理【本文首发于唐霜的博客】本文作者：唐霜，转载请注明出处。念的应用架构，往往是立足于复杂的业务系统【作者：唐霜】本文版权归作者所有，未经授权不得转载。（往往是B端应用），我认为只有围绕一个处【访问 www.tangshuang.net 获取更多精彩内容】著作权归作者所有，禁止商业用途转载。理复杂业务为中心而搭建的系统，才需要从D【本文首发于唐霜的博客】未经授权，禁止复制转载。DD的理念去思考和实践，但在最近，（基于【版权所有】唐霜 www.tangshuang.net本文作者：唐霜，转载请注明出处。我的切身体会）我发现这一想法是错误的，DDD不仅复杂的B端业务系统的有用工具，本文版权归作者所有，未经授权不得转载。【本文受版权保护】而且在C端常规的业务应用中，也具备指导作本文作者：唐霜，转载请注明出处。著作权归作者所有，禁止商业用途转载。用。原创内容，盗版必究。

之前我之所以强调只有B端业务需要DDD，【访问 www.tangshuang.net 获取更多精彩内容】本文作者：唐霜，转载请注明出处。是因为我觉得DDD本身所带来的复杂性很强【版权所有】唐霜 www.tangshuang.net【访问 www.tangshuang.net 获取更多精彩内容】，需要沉淀的东西很多，对于开发而言具有阻【版权所有】唐霜 www.tangshuang.net未经授权，禁止复制转载。碍性，会拖慢开发进度，特别是在追求快速迭【访问 www.tangshuang.net 获取更多精彩内容】【本文首发于唐霜的博客】代的C端会拖慢进度。同时，我也认为C端应【作者：唐霜】【关注微信公众号：wwwtangshuangnet】用不存在“业务”的概念，也就无所谓用DD【本文受版权保护】【未经授权禁止转载】D去解决业务核心复杂性。但是，当我现在开原创内容，盗版必究。本文版权归作者所有，未经授权不得转载。始参与C端应用开发时，我发现，即使是C端【版权所有，侵权必究】转载请注明出处：www.tangshuang.net应用，它也是有业务的。当一个应用是以用户完成某种目标，需要在多【关注微信公众号：wwwtangshuangnet】【本文首发于唐霜的博客】方数据中进行博弈时，就开始拥有一定的业务【作者：唐霜】【访问 www.tangshuang.net 获取更多精彩内容】属性。所以，现在来看，除了类似微博、新闻、短视【版权所有】唐霜 www.tangshuang.net【原创不易，请尊重版权】频等这类纯粹娱乐的应用之外，其他大部分应【访问 www.tangshuang.net 获取更多精彩内容】原创内容，盗版必究。用都具备业务性质，大到类似淘宝一类的电商【访问 www.tangshuang.net 获取更多精彩内容】【本文受版权保护】平台，小到政府的一个办事小程序，甚至一个本文作者：唐霜，转载请注明出处。【原创内容，转载请注明出处】乘车码，背后都有多方数据在博弈，都具备业转载请注明出处：www.tangshuang.net【版权所有】唐霜 www.tangshuang.net务，甚至一旦这种博弈的强度提升（例如加入著作权归作者所有，禁止商业用途转载。【本文首发于唐霜的博客】风控相关的逻辑），其业务复杂度就会呈指数【版权所有，侵权必究】【原创不易，请尊重版权】级增长。

因此，我现在改变了我的想法，我认为，【版权所有，侵权必究】DDD作为一种指导架构设计、技术实现、设【本文受版权保护】【作者：唐霜】计研发的理念，无论在B端C端还是哪里，只转载请注明出处：www.tangshuang.net转载请注明出处：www.tangshuang.net要系统具备业务性质，都具备指导意义。

1 应用架构设计【版权所有，侵权必究】

在其他文章中我已经聊了很多有关基于DDD【本文首发于唐霜的博客】【版权所有】唐霜 www.tangshuang.net来设计应用架构的内容，这里就不再赘述。我原创内容，盗版必究。【关注微信公众号：wwwtangshuangnet】现在想要讲的是一些更微观的东西。

C端应用是否应该在一开始，就进行复杂的架原创内容，盗版必究。【原创内容，转载请注明出处】构设计？

我认为需要。C端应用在早期一定是追求快速【版权所有，侵权必究】著作权归作者所有，禁止商业用途转载。迭代的，因此会积累非常多的债务。当债务积本文作者：唐霜，转载请注明出处。【本文受版权保护】累到一定程度时，一定会阻碍开发迭代的效率【关注微信公众号：wwwtangshuangnet】著作权归作者所有，禁止商业用途转载。，因此，应该重构。不过，按照《重构》的讲【访问 www.tangshuang.net 获取更多精彩内容】【本文首发于唐霜的博客】法，重构应该持续，时时刻刻在重构，但是这【版权所有，侵权必究】【版权所有，侵权必究】种只存在理想情况下。我们这里所指的重构，【原创不易，请尊重版权】本文作者：唐霜，转载请注明出处。一定是在一个阶段，对整个项目代码进行刮骨【访问 www.tangshuang.net 获取更多精彩内容】【原创内容，转载请注明出处】疗伤式的全部重来。但是，我们会遇到一个非【原创内容，转载请注明出处】【原创不易，请尊重版权】常巨大的问题，就是原有的业务逻辑可能在重本文作者：唐霜，转载请注明出处。著作权归作者所有，禁止商业用途转载。写时，被疏忽而遗漏掉。而前端用来对抗这种【原创内容，转载请注明出处】【原创不易，请尊重版权】不确定性的武器不多。

一种方案是老代码完全不要动，甚至继续迭代本文版权归作者所有，未经授权不得转载。【关注微信公众号：wwwtangshuangnet】，虽然痛苦，但是起码能保证业务逻辑没有被未经授权，禁止复制转载。【本文首发于唐霜的博客】破坏。在将来有机会，再利用新架构，对这块本文版权归作者所有，未经授权不得转载。本文版权归作者所有，未经授权不得转载。业务进行推倒重来的重构，通过灰度、AB等【版权所有，侵权必究】著作权归作者所有，禁止商业用途转载。方式逐步迁移。手段有多种，例如微前端、M原创内容，盗版必究。著作权归作者所有，禁止商业用途转载。PA（多页应用，不同URL跳转）、在新架著作权归作者所有，禁止商业用途转载。原创内容，盗版必究。构下写一个可支持原始代码运行的沙盒工具…【本文首发于唐霜的博客】本文版权归作者所有，未经授权不得转载。…

另一种则是直接全部重写，且不必去考虑原始未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。实现，翻出产品文档，按照文档的逻辑重新实【本文首发于唐霜的博客】【转载请注明来源】现，像写一个新功能一样。而这样做，意味着【版权所有】唐霜 www.tangshuang.net【转载请注明来源】我们可以在线上跑两套代码，相互验证，也是【原创内容，转载请注明出处】原创内容，盗版必究。不错的选择。

如果说B端系统像一座笨重的基地，通过不断【原创不易，请尊重版权】【关注微信公众号：wwwtangshuangnet】的在原来的基础上叠加呈现堆积如山的模式来未经授权，禁止复制转载。【版权所有】唐霜 www.tangshuang.net实现系统的扩张，那么C端应用就像一张星链【访问 www.tangshuang.net 获取更多精彩内容】著作权归作者所有，禁止商业用途转载。网，通过不断增加数量以铺张出更大的面积的【版权所有】唐霜 www.tangshuang.net原创内容，盗版必究。模式来实现业务的扩张，两者的一个是纵向发【版权所有，侵权必究】【本文首发于唐霜的博客】展一个是横向发展，看上去，纵向发展的B端【作者：唐霜】【版权所有】唐霜 www.tangshuang.net系统更需要架构，来实现部分和整体的融洽，【版权所有】唐霜 www.tangshuang.net未经授权，禁止复制转载。而横向发展的C端应用似乎可以分布式存在，原创内容，盗版必究。【版权所有，侵权必究】甚至可以各自独立。但当我们回到开发层面，【访问 www.tangshuang.net 获取更多精彩内容】【版权所有】唐霜 www.tangshuang.net我们就会发现，这种分布式扩张的模式，更难原创内容，盗版必究。未经授权，禁止复制转载。把握架构设计，因为它们看上去可以独立，但【访问 www.tangshuang.net 获取更多精彩内容】【关注微信公众号：wwwtangshuangnet】是它们大部分又要共通，如果不通，当某些部【本文首发于唐霜的博客】本文作者：唐霜，转载请注明出处。分需要升级时，不可能到所有节点上去一个一【未经授权禁止转载】【访问 www.tangshuang.net 获取更多精彩内容】个升级。

因此，【关注微信公众号：wwwtangshuangnet】把薄薄的星链，按照厚厚的基地来设计，才能原创内容，盗版必究。原创内容，盗版必究。在源头解决将来的很多问题。

有人会说，你前面不是讲C端要快速迭代，前【未经授权禁止转载】原创内容，盗版必究。期要快吗？是，但并不意味着要快，就不能按未经授权，禁止复制转载。【本文首发于唐霜的博客】DDD来设计，也不是说按DDD来实现，就【访问 www.tangshuang.net 获取更多精彩内容】原创内容，盗版必究。一定是慢。在架构设计中，有些东西我们必须本文作者：唐霜，转载请注明出处。【访问 www.tangshuang.net 获取更多精彩内容】去做，而如何做好这些，却各有各的不同。

例如，我们必然会写数据请求的部分，毕竟在未经授权，禁止复制转载。【版权所有，侵权必究】后端看来，“前端不过就是渲染界面而已“，【未经授权禁止转载】转载请注明出处：www.tangshuang.net没有数据来源，实在是巧妇难为无米之炊。可本文作者：唐霜，转载请注明出处。本文作者：唐霜，转载请注明出处。以说，如今的前端应用，99.9%都会有数【未经授权禁止转载】【原创不易，请尊重版权】据请求这个部分，剩下的0.1%可能是古老原创内容，盗版必究。【转载请注明来源】的php或jsp输出的网站。那么，如何去【关注微信公众号：wwwtangshuangnet】本文作者：唐霜，转载请注明出处。设计数据请求和数据源管理，就是八仙过海各未经授权，禁止复制转载。【原创不易，请尊重版权】显神通了。

再例如，通用的底层UI组件库，每个项目组【访问 www.tangshuang.net 获取更多精彩内容】【版权所有，侵权必究】都有一套，那么如何去设计这套组件库，就各【作者：唐霜】未经授权，禁止复制转载。执一词，各自把牛B吹上天，最后在业务中用本文版权归作者所有，未经授权不得转载。原创内容，盗版必究。时，仍然是不断的改来改去。

我们需要遵循一种理念，让这些共通的东西在【版权所有】唐霜 www.tangshuang.net【版权所有，侵权必究】项目设计之初就稳定下来，不是最好的才是最原创内容，盗版必究。【版权所有】唐霜 www.tangshuang.net好的，合适的才是最好的。一个团队一定有自【关注微信公众号：wwwtangshuangnet】本文作者：唐霜，转载请注明出处。己的特殊性，在团队内能形成一种无形的设计【原创不易，请尊重版权】原创内容，盗版必究。模式，就必须要去遵循它，即使在别人看来很转载请注明出处：www.tangshuang.net本文作者：唐霜，转载请注明出处。奇怪。

我们要找到一种感觉，即在项目的架构层面，本文作者：唐霜，转载请注明出处。著作权归作者所有，禁止商业用途转载。可以去避免将来可能出现的问题。如果去避免【转载请注明来源】【本文首发于唐霜的博客】呢？很简单，就是无论将来的技术发生什么变化，这些复杂【原创内容，转载请注明出处】【未经授权禁止转载】的代码都可以被再次使用。没错，只要我们的代码设计为脱离具体环境，著作权归作者所有，禁止商业用途转载。转载请注明出处：www.tangshuang.net是一种纯粹的业务、逻辑的时候，就可以再将著作权归作者所有，禁止商业用途转载。著作权归作者所有，禁止商业用途转载。来被重复使用，即使可能将来有更好的实现方原创内容，盗版必究。【作者：唐霜】式，但是起码用上这些老代码不需要什么成本【本文首发于唐霜的博客】【原创不易，请尊重版权】就可以继续使用它们的逻辑。

例如数据请求，当我们从vue2升级到vu【原创内容，转载请注明出处】【原创内容，转载请注明出处】e3时，这部分代码不需要被修改就可以直接【原创不易，请尊重版权】【本文受版权保护】使用。例如UI组件库，当我们需要web和本文作者：唐霜，转载请注明出处。【原创不易，请尊重版权】小程序拥有相同样式时，不需要修改即可使用原创内容，盗版必究。本文版权归作者所有，未经授权不得转载。需要的组件。一旦我们的架构设计为这种脱离著作权归作者所有，禁止商业用途转载。【作者：唐霜】了具体环境的设计，就可以在将来立于不败之未经授权，禁止复制转载。著作权归作者所有，禁止商业用途转载。地。

2 从细节去重新审视自己本文版权归作者所有，未经授权不得转载。

让我们现在来想象一个场景，需求里是这么描【本文首发于唐霜的博客】【本文首发于唐霜的博客】述的：“当库存不足时，界面上需要展示库存著作权归作者所有，禁止商业用途转载。著作权归作者所有，禁止商业用途转载。不足的提示“。很常见的一个描述对吧。现在【未经授权禁止转载】本文作者：唐霜，转载请注明出处。问题来了，这里”展示提示“我们是怎么实现未经授权，禁止复制转载。未经授权，禁止复制转载。的呢？80%的人是不是如下：

<StockTips :isShow="isStockTipsShow"></StockTips>

我们用一个isStockTipsShow【原创内容，转载请注明出处】【本文受版权保护】状态来控制提示的是否展示，然后就是对is本文版权归作者所有，未经授权不得转载。【版权所有，侵权必究】StockTipsShow进行定义或变更【转载请注明来源】本文版权归作者所有，未经授权不得转载。：

isStockTipsShow.value = stock === 0;

或者：【转载请注明来源】

get isStockTipsShow() {
  return this.data.stock === 0;
}

总而言之，我们在不断考虑用于控制“展示不【版权所有，侵权必究】【本文受版权保护】展示”的实现。但是，你有没有想过一个问题著作权归作者所有，禁止商业用途转载。【本文受版权保护】，当我们将来需要将“展示提示“的条件进行【原创不易，请尊重版权】【转载请注明来源】修改，例如”当库存不足，且用户参与过某活未经授权，禁止复制转载。本文版权归作者所有，未经授权不得转载。动，且系统中存在某种情况“，那么我们如何本文作者：唐霜，转载请注明出处。本文作者：唐霜，转载请注明出处。为其提供这种控制逻辑呢？

如果此时，我们换一种视角，我们创建一个属未经授权，禁止复制转载。未经授权，禁止复制转载。性，名为 isStockEmpty 而且将它从vue组件的状态中脱离出来，未经授权，禁止复制转载。未经授权，禁止复制转载。和vue没有任何关系。于此同时，我们甚至【关注微信公众号：wwwtangshuangnet】原创内容，盗版必究。把“提示”这个看上去是UI层面的东西，也著作权归作者所有，禁止商业用途转载。原创内容，盗版必究。变成了一种抽象的符号，与vue无关，例如【版权所有】唐霜 www.tangshuang.net本文作者：唐霜，转载请注明出处。这样：

subscribe(isStockEmpty, StockEmptyTips) 

而这个代码，脱离了任何环境，都运行正常。未经授权，禁止复制转载。转载请注明出处：www.tangshuang.net至于在UI上是不是要展示这个提示，则完全原创内容，盗版必究。著作权归作者所有，禁止商业用途转载。是在UI层去实现它。

呃……【转载请注明来源】isStockTipsShow 和 未经授权，禁止复制转载。isStockEmpty 有区别吗？有！本质的区别。本文作者：唐霜，转载请注明出处。

isStockTipsShow 是在想我这个界面如何去控制，而 【版权所有】唐霜 www.tangshuang.netisStockEmpty 是在想从业务上讲我什么情况下代表没有库原创内容，盗版必究。未经授权，禁止复制转载。存了。当时间经历了很久，我们需要将vue【关注微信公众号：wwwtangshuangnet】【作者：唐霜】2迁移到vue3使用时，就会发现，前一种著作权归作者所有，禁止商业用途转载。转载请注明出处：www.tangshuang.net思维想要改动这个逻辑是万万不敢，而后一种【未经授权禁止转载】【版权所有，侵权必究】思维则是对组件随便改，但可复用的业务逻辑【关注微信公众号：wwwtangshuangnet】未经授权，禁止复制转载。绝对不改。我们通过写vue代码去适应业务本文版权归作者所有，未经授权不得转载。【版权所有，侵权必究】，而非写业务代码去适配vue组件。

你看，一个简简单单的命名，从业务的角度去【原创不易，请尊重版权】著作权归作者所有，禁止商业用途转载。命名，和从UI组件的角度去命名，就会对我【关注微信公众号：wwwtangshuangnet】未经授权，禁止复制转载。们将来带来可怕的差别。其本质，是思维上的著作权归作者所有，禁止商业用途转载。【访问 www.tangshuang.net 获取更多精彩内容】差异。

3 模块【未经授权禁止转载】

将有关业务的琐琐碎碎集中在一起，就是一个本文版权归作者所有，未经授权不得转载。未经授权，禁止复制转载。业务模块，但很让人崩溃的是，模块往往没有【访问 www.tangshuang.net 获取更多精彩内容】未经授权，禁止复制转载。单一的出口，你不可能从单一出口使用这个业本文作者：唐霜，转载请注明出处。【作者：唐霜】务，而必须在使用这个模块的外围应用（可能转载请注明出处：www.tangshuang.net本文作者：唐霜，转载请注明出处。是另外一个模块）选择不同的出口进行使用，本文作者：唐霜，转载请注明出处。未经授权，禁止复制转载。这里最复杂的，就是我们需要对这些出口进行编排【转载请注明来源】。而往往，业务模块会被多个外围应用使用，【原创内容，转载请注明出处】转载请注明出处：www.tangshuang.net否则就没有必要作为模块存在。不同的外围应【作者：唐霜】本文版权归作者所有，未经授权不得转载。用调用相通出口时，则会让应用中编排业务的【转载请注明来源】原创内容，盗版必究。调用变得混乱。而且还会遇到嵌套中的模块，本文版权归作者所有，未经授权不得转载。著作权归作者所有，禁止商业用途转载。同时依赖同一模块，更加复杂的编排和依赖关【版权所有，侵权必究】【本文受版权保护】系。

而一种工作流（workflow）的模式，【版权所有】唐霜 www.tangshuang.net【本文受版权保护】则可以解决这种编排的难以琢磨问题。

业务数据和状态的变更，总是存在于某种业务转载请注明出处：www.tangshuang.net【本文受版权保护】的流转之中，而这个流转模型，可以确保业务【未经授权禁止转载】【本文受版权保护】流转在被不同模块调用时保持一致性。工作流【版权所有，侵权必究】【原创内容，转载请注明出处】模式在前端如何去实践我自己也在探索中，我未经授权，禁止复制转载。【原创内容，转载请注明出处】只是认为，能够确保被不同地方调用的同时，【版权所有，侵权必究】本文版权归作者所有，未经授权不得转载。还能确保业务的一致性，是一种很酷的模式。

4 代码量【本文首发于唐霜的博客】

我最近发现，tree shaking并不著作权归作者所有，禁止商业用途转载。【本文受版权保护】好用，控制代码量，使得线上代码体积减少，【访问 www.tangshuang.net 获取更多精彩内容】【未经授权禁止转载】其实是很难的一件事。但是，……但是这和D【版权所有】唐霜 www.tangshuang.net【作者：唐霜】DD有什么关系？

当我们采取一种架构策略时，在具体代码实现本文作者：唐霜，转载请注明出处。原创内容，盗版必究。上，常常会因为架构本质的区别而导致最终的【原创不易，请尊重版权】【转载请注明来源】代码量差距巨大。架构的理想程度，常常和代【原创不易，请尊重版权】【原创内容，转载请注明出处】码体积成正比，因为，要实现某种理想的架构【原创不易，请尊重版权】【作者：唐霜】，代码分散、粘合、为了实现模式的故意使然【转载请注明来源】【版权所有，侵权必究】、符合架构的文件目录结构设计等等，都会增本文作者：唐霜，转载请注明出处。转载请注明出处：www.tangshuang.net加最终的代码量。

因此，我们不应该追求最理想化，我们必须向【访问 www.tangshuang.net 获取更多精彩内容】著作权归作者所有，禁止商业用途转载。现实低头，过渡理想化，并不是最好，相反，【访问 www.tangshuang.net 获取更多精彩内容】原创内容，盗版必究。过渡一定带来代价。在实现DDD架构时，我【访问 www.tangshuang.net 获取更多精彩内容】【版权所有，侵权必究】们应该保持C端应用本身的轻量化特征，取精【访问 www.tangshuang.net 获取更多精彩内容】【本文首发于唐霜的博客】华的部分。