在我们每个人的大脑里面，对一件事情，一类事物，如果没有一个概念的话，我们的大脑会有意识地躲避那件事情，从而不去想它，更不会继续思考它。
微服务、DDD、中台这些词汇，恰恰是这样的概念。正是有了这样的概念，才让我们一而再地学习它，思考它，钻研它。因为这些词汇、这些概念一直驻留在你的脑子里面。
可是，你会说，现在微服务不火了呀，没有多少人谈它了，中台更是，以前搭中台，现在都喊着拆中台呢。
然而也是历史告诉我们，当我们被技术大词狂热鼓舞的时候，心里得清楚，真正希望了解这个技术的人并不多，要么应激怕掉队，要么投机想上位。只有浪潮退去，我们才能真正静下心来看看它是什么，以及怎么做。
只有真正想学习它，了解它，应用它的人们才会那么的专一，而不受这样的词汇、概念的生命周期所左右。因为，毕竟这些都是很有价值的技术！
正是这样，我提出微服务的二次创业的说法。
”二次创业，企业在取得高速增长之后，为了谋求进一步的发展而进行的内部变革过程。“
那，一般二次创业是怎么做的呢。
”在企业已有的基础上，进行管理的科学化，不断挖掘内部潜力，以求得进一步的发展。“
而，我们的二次创业，并没有那么商海沉浮与动荡，我们是一次在原有的微服务应用的基础上，再一次学习的过程，哪怕是再将之前的理论，重新趟过一遍，只是这一趟更有痕迹一些。
我来举一个例子。
比如，微服务有九种特质，其中有一项，阐述起来是这样描述的，微服务中的服务应该以业务能力为粒度。
那么，这里的业务能力应该如何理解，到底什么是业务能力。
在二次创业中，要弄清这个业务能力，还是让我们先从贫血模型和充血模型说起。
贫血模型是事务脚本模式，写脚本肯定是要比写”文章“来的快多了，关键是脚本还真是能完成被要求的任务，比如，一个需求，我需要计算人的生日距离现在还有多少天，还要实现这个人干活写代码，还有休息。任意选一个Service类，写一个方法就能搞定。而且原来的那个Person类，显得是那么的“干净”，里面全是Get和Set，没有任何行为。
充血模型是领域模型模式，实现起来就相对”复杂”些，那么我觉得这种复杂也是相对贫血模型的脚本式编程来说的。比如，还是计算，人的生日距离现在多少天，还是写代码和休息，那么我就会把这个动作放到Person这个对象里面，这个类会显得那么”复杂“。
充血模型真的那么”复杂“，贫血模型真的那么”简单“吗？
你仔细回忆一下，贫血模型的代码结构，Service类，Person类，使用它们的Client类，一个也不少，而且这段结构最终的样子就是下面这样。
代码语言：javascript复制/**
* 贫血模型
*/
public class Client {
@Resource
private PersonService personService;
@Resource
private WorkService workService;
public void test() {
Person person = new Person();
personService.setAgeByBirth(person);
workService.code(person);
personService.sleep(person);
}
}
我不就是计算一个人的日常那么简单的三件事吗？就一定要引入这么多的类吗？
我想看看使用充血模型来实现上面这个逻辑，还需要那么多代码吗，充血模型的代码结构是下面这样的。
代码语言：javascript复制/**
* 充血模型
*/
public class Client {
public void test() {
Person person = new Person();
person.setAgeByBirth();
person.code();
person.sleep();
}
}
这个时候，你再来对比一下，上下两处代码结构，哪一个让你的认知成本更大呢？哪一个更符合自然语义呢？
贫血领域模型的根本问题是，它引入了领域模型设计的所有成本，却没有带来任何好处。
只有当你充分使用了面向对象设计来组织复杂的业务逻辑后，这一成本才能够被抵消。如果将所有行为都写入到Service对象，那最终你会得到一组事务处理脚本，从而错过了领域模型带来的好处。而且当业务足够复杂时， 你将会得到一堆爆炸的事务处理脚本。
更”可气“的是，贫血模型的代码结构下，原本属于一个对象的能力，却被散落在工程的各个”角落“，这样的情况下，是根本没有办法形成一个”可复用的能力“。
当然，贫血模型下，也就没有业务能力，更为精确的说法是我们没有办法把业务能力抓起来，分散、不可复用。
哈，到了这里，就又来一个问题，那么，如何来寻找可复用的能力呢？
抽象。
上面也讲到，充血是领域模型模式，领域里面最重要的一个环节就是业务建模，而业务建模最重要的动作就是抽象。
一说抽象，大家觉得这会很困难吗，抽象不就是对事物的高度概括，我们在OOP中也经常提到，面向抽象编程。
但是，难就难在抽象的度。
在抽象的过程中，你既会遇到泛化的概念，也会遇到具体的实体。
如果泛化概念不够，那么业务模式就会退化为具体的业务功能了；但如果泛化概念太多，则容易引起过度抽象，丧失业务模式的价值。
只有在系统有了聚合的业务能力之后，我们的系统才能力出一孔，把主要逻辑收敛，个性逻辑开放，在这样的系统环境里面，才能够有基础去建成一个可以支撑多个前台业务的中台系统。
是的，中台系统。
比如我们常见的电商网站上面的促销功能，按照地域划分，有国内的促销，泰国的促销，印尼的促销等，他们所使用的促销功能是一样的吗？这些运营的前台团队大概率不会是一个，但是大致的主要功能逻辑肯定是相同的，但是一些细节上可能会存在差异，比如国内、国外的电商政府政策不同，那么就会导致有差异化的逻辑出现。
那么，这里的包含主要促销逻辑能力的系统，就是一个促销中台系统。
二次创业，切记勿骄勿躁，不要因为有一次的基础，就可妄为，我们一样会遇到复杂的问题，遇到分布式的陷阱，遇到伪服务的障碍。
问：”怎样吃掉一头大象？“
答：”一次咬一口“
构建软件也一样，唯一方法是增量递进。
有一次，就有二次、三次。没有终，以终为始，终不是末了，终是里程碑。我们应该在技术之路上，永不停歇，做一个坚定的技术务实主义者，不能随意被行业上，社会上的技术热词所牵引。
----END----
这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。
与爱学习、爱思考、爱记录的你共勉。
参考资料：
https://mp.weixin.qq.com/s/8YD9sqTuZGJEpVZPYY-aBQ
https://time.geekbang.org/column/article/406190
