电饼铛

今天就从电饼铛说起。

上周，我家的电饼铛坏了，原因可能是清洗过后线路短路导致的。那个老式电饼铛确实用了好些年，且功能单一，基本上除了开关键，再也没有什么可以按钮的地方了，不过老妈却一直用的很顺手。

而对我来说，这确实个好消息，终于可以换一个好电饼铛了。于是在网上买了一个七百多的苏泊尔的电饼铛，这一下子感觉高大上了许多，很多内置模式，可以支持煎蛋，煎饼，炸鸡翅等多种模式，对温控的把握也十分精准。

不过，对于我老妈来说，她并没有显得多兴奋，我将使用说明一一教给她用，但老妈最终只选择一种用法：打开开关，选择自定义模式，一切都靠经验去判断电饼铛的温度和对食材的感觉，其他所有的内置模式，对她老人家来说，好像确实是多余的。

对此，我有点陷入沉思，总觉得有一种似曾相识的感觉。仔细思考，其实这种情况在编程过程中屡见不鲜。其实这不就是我们微服务架构中经常会遇到的一种情况么....

好的，接下来，如果把我和我老妈的上述行为抽象为代码，可以写成如下：

老妈做煎蛋：

1/**
2 *老妈做煎鸡蛋
3 */
4public class MainApplicaiton{
5    /**
6     *电饼铛
7     */
8    @Resource
9    private DianBingCheng dianBingCheng;
10    /**
11     *老妈的判断服务类
12     */
13    @Resource
14    private MotherCheckService matherCheckService;
15    /**
16     * 老妈的行为服务 
17     */
18
19    private MotherBehaviorService MotherBehaviorService;
20
21    public void execute() {
22        //打开电饼铛
23        MotherBehaviorService.Open(dianBingCheng);
24        //检查温度
25        matherCheckService.CheckTemperature(dianBingChengAggregate);
26        //开始煎鸡蛋
27        MotherBehaviorService.fryEggs();
28        //检查是否熟了
29        matherCheckService.CheckRipe()；
30        //完成，关机盛盘
31        matherService.complete();
32    }
33}
34

我做煎蛋：

1public class MainApplicaiton {
2    /**
3     * 电饼铛聚合根
4     */
5     @Resource
6     private DianBingChengAggregateRoot dianBingChengAggregate;
7
8     public void execute() {
9        //开机
10        dianBingChengAggregate.open();
11        //煎蛋模式
12        dianBingChengAggregate.fryEggs();
13        //完成，关机盛盘
14        dianBingChengAggregate.complete();
15     }
16}
17

大家可以看出这两者的实现区别，我们有时候需要思考一下，我不就是处理一个日常特别简单的事情，一定要引入那么多的服务类么？

贫血模型和充血模型

可能大家感觉出来了，这两种实现，就是领域驱动设计中典型的贫血模式和充血模式。这里不得不先说一下贫血模型和充血模型。

贫血模型是事务脚本模式。对于程序员来说，脚本呢肯定是要比写设计说明书要快的多了。比如，我们要设计一个订单流程，包括下单，取消，售后，拆单等情况下的订单流转，那么我们就就会任选一个Service类，写一个方法就能搞定，而这时，原来的那个order类中，就会非常非常的“清爽”，里面全是GET方法和Set方法，没有任何行为。而很多人喜欢给这个order类一个定义，叫OrderDomain，订单领域模型。当然我更喜欢叫这种模型为DB模型，是面向数据库的，而不是面向领域业务的。

而充血模型是才是典型的领域模型模式。他实现起来相对复杂，但这种复杂也是相对的，还是上面的例子，我们会在Order这个对象中放入响应的动作行为的方法，例如我们更新订单状态不会用setStatus（）这种方法，而会封装类似orderCancel()，orderComplete()的这种业务行为方法，当然这种方式会让这个类略显“复杂”。

总结一句话，真正的领域模型会把数据和行为聚合在一起，形成聚合根，对外提供基于行为的方法，而非脚本化的增删改查。只有这样才能够更好的对微服务进行拆分。

如果仅是贫血模型其实不是对系统架构危害最大的，想我们已经很熟悉的MVC，通过贫血模型也可以写出复杂的高效快捷的系统。

但是，有一种危害就会很大了：

就像好多同学用这面向对象的语言，写着面向过程的代码一样，很多同学喜欢用冠以领域驱动设计的噱头，却写着MVC式的“面向数据库编程”，它最大的问题是你引入了领域模型设计的所有成本，但却没有带来任何一丝的收益。

只有当你充分使用了面向对象设计来组织复杂业务逻辑之后，才能抵消这种成本。如果将所有行为都写入一个一个的Service类，领域是被割裂的，那最终你会得到一组事务处理脚本，从而错过了领域模型带来的好处，而且当业务足够复杂时，你将会得到一堆爆炸的事务处理脚本。

此外，你还会发现，

本来属于一个领域的能力，却被散落在了工程的各个角落。这样一来，根本无法形成一个可复用的能力。

当然有同学也会提出疑问：“我的业务场景中领域之间其实关系比较紧密，我会经常遇到会触发同时跟不同领域行为相关的业务，在这种情况下，我就通过一个个的Service扩展，这就是一种显而易见的解决方案呀~~ ”

其实有这种想法的同学，主要是对领域驱动设计理解不深刻的，同时又对传统的MVC框架开发根深蒂固。

其实领域驱动设计早已给出它的最佳实践，那就是领域事件。而面向事件的编程思想对于后端来说，是一种非常高效和优秀的思想。通过领域事件，我们可以实现领域之间的解耦，同时也维护了领域模型的独立性和数据一致性。而关于领域事件又是一个很大的话题，以后有机会再聊。

思考

在我们每个人的大脑里，对于一件事，如果没有概念和理解的话，我们会有意识的躲避那件事，或者用自己熟悉的概念去套用。微服务，DDD，中台这些词汇，恰恰是这样的概念。这是有了这些概念，才让我们不断的努力去学习它，思考他，钻研他。

在微服务和DDD这波浪潮里，很多同学都想用这些概念来包装自己，就像我面试过的很多候选者，他们中的很多都在简历中写了精通领域驱动设计，同时也能说出一些聚合根，实体，值对象等概念，但是实际落地就变成了贫血模式的代码。

所以，对于程序员来说，最核心的能力并不是你会几种语言，会几个架构或者几个名词概念，而是理解那些概念并转化成自己的编程思想。

同时，

勇于创新和敢于推翻自己的已有认知，也是一名程序员能否有一直前进的动力的前提。

【程序员日记】---当“微服务”遇到了“电饼铛“

电饼铛

贫血模型和充血模型

思考

评论区

相关推荐