本文集说的都是些平凡的小事，但往往是这些小事区分了产品的伟大与平庸。

1.杂谈业务组件标准化

(1)感觉自己萌萌哒

前面章节提到的“开发环境标准化”、“工程标准化”、“三方件标准化”都有明确的、可量化的标准，有标准就可以看护。

但“与业务强相关”的业务组件，就很难找到“标准”——您可能会说业界那些架构模式、设计模式不就是给我们的明灯吗？举个例子，“微服务”的方法论只说您的产品只要划分成了微服务，就可以享受到很多好处，但是，您的产品已经有了千万行的存量代码，怎么划分呢？这些架构模式就不怎么回答了。

于是，实战中，业务组件因为没有标准，所以就“跟着感觉走”，通常还是跟着“领导的感觉走”。如果领导没有编码经验、没有深入客户需求，这种感觉简直就是灾难。

图1

感觉，有两个特征：一是主观性，二是以自我为中心。所以，跟着感觉走的人和产品，是不是总觉得自己萌(不)萌(靠)哒(谱)？

图2

(2)标准化与场景化的矛盾

再来说说矛盾：标准化强调军事化管理，要整齐划一。场景化强调具体问题具体分析，要因材施教。这两种针锋相对的流派，在实战中如何取舍与平衡呢？

想说清这个问题，笔者先引用《神雕侠侣》中独孤求败的墓志铭：

第一把青锋长剑——“青锋长剑，凌厉刚猛，无坚不摧，弱冠前以之与河朔群雄争锋”

第二把紫薇软剑——“紫薇软剑，三十岁所用，误伤义士不详，乃弃之深谷”

第三把玄铁重剑——“重剑无锋，大巧不工，四十年前恃之横行天下”

第四把腐朽木剑——“四十岁之后，不滞于物，草木竹石皆可为剑。自此精修，渐进于无剑胜有剑之境”

图3

标准化就是定式，是程序猿的“青锋长剑和紫薇软剑”。老前辈们总结出一种的“套路”，这种套路在合适的场景下使用最安全、最稳妥、最大概率的提高新手的胜算。所以，定式一定要学，而且要虚心的学、深入的学。

标准化的误区是“生搬硬套”。初学者仅仅理解了定式的招式，却没有理解定式的心法，“合适的场景”就是定式的心法——只有在这个特定的场景下使用这个定式才最合适——笔者工作初期很迷信设计模式，把市面上能买到的设计模式的书都读了一遍，在产品代码中大量使用设计模式，结果弄巧成拙到后来自己都看不懂自己的代码。这就是风骚的代价。。。

图4

“场景化”就是具体问题具体分析，是程序猿的“玄铁重剑和腐朽木剑”。这个阶段就是将“定式”烂熟于胸的程序猿，不断通过一个个实战案例，对“定式”理解的更加透彻，运用的更加灵活自如。

“场景化”的能力提升似乎没有更好的办法，只有通过实战训练和经验总结。

写到这里，笔者已经放弃了从方法论层面进行证明与探索了。Why？

标哥的口头禅：“量变引起质变”，即当代码规模数量级增长时，架构面临的挑战就会指数级增长。只经历过10万行代码规模的程序猿绝无可能看看书就能具备千万级代码规模的架设能力。因为在一次次的实战训练中，程序猿的大脑会经历无数次主动+被动的“抽象、总结”的思维训练

也就是说，有一种痛就叫做你不经历就不会懂的痛。

图5

2.一种标准化的实现

下面笔者以一个VUE+SpringBoot的系统为例，列举出笔者认为比较实用的标准化实现

(1)MVC、MVP、MVVM=>WCSR

MVC、MVP、MVVM是业界常规的架构模式，我们简单回顾一下它们的含义：

MVC：Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

MVP：Model-View-Presenter ；MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。

MVVM：Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。ViewModel实现了数据绑定。

WCSR本质就是MVC，为业务组件横向切分的一种标准(图6)

Website：用于承载页面相关的容器，与JS端进行对接

Composite：组合调度各类原子能力。

Single：原子能力

Repository：MO、VO、持久化相关。

图6

(2)DDD=>对业务进行合理划分的一种方法论

只是摘抄DDD繁多术语中的部分，看到DDD体系的大致思路：

Domain(领域)：一个领域具有类似的核心业务，解决类似的问题域

Bounded Context(界限上下文)：将Domain划分成N个子域，Bounded Context用来描述子域间的关系。Bounded Context实战中通常会变成一个子系统or模块。

Domain Model(领域模型)：表达实体概念(例如：老师、学生)、过程概念(对老师出题考学生)

Entity(实体)：class Person，有唯一标识

ValueObject(值对象)：int a=3;

Domain Service(领域服务)：调度多个DomainModel，纯粹的动作，不适合建模为对象

Aggregate(聚合)：描述Entity、ValueObject的关系

Factory(工厂)：创建Entity、ValueObject、Aggregate

Repostitory(仓库)：持久化到DB

个人认为，DDD设计了很多严谨规范的术语以及分析业务需求的流程(仔细阅读图7就能理解DDD是个什么药方)。在复杂的业务需求中，能够相对条理化、规范化的纵向划分业务子系统、业务组件等。

图7

笔者不是DDD的铁粉，但DDD至少是一个相对系统的方法论，实战中至少可以让项目组的关键角色相对快速达成一致的设计思路。

图8

3.总结

本文的主题很难表述清楚，笔者只能列举所处项目常用的一种实现方式进行阐述，权当抛砖引玉，有一种痛不经历真的无法感同身受。

PS：笔者程序猿生涯深受标哥的指点和影响，文中常常引用他老人家经典的观点，因此和小伙伴们制作了标哥表情包，以表敬意。

图9