一周技术学习笔记(第57期)-需求那么多？-其实就两种

我的同事小A是一位后端研发工程师，最近在抱怨需求实在太多。

业务方1要求在给商家返回的订单信息中增加库存剩余情况；

业务方2要求在给用户发放权益前增加对用户积分的判断；

业务方1又要增加这个订单，如果参与促销的话，再给商家返回单次促销收益情况；

业务方X。。。

我跟小A聊了下。

系统是不是已经按照微服务的理念去实践的，是。

那么一个后端系统是不是下面这样的交互方式？

 图1

是。

我说，需求其实就两种。

第一种：从多个服务中聚合数据来为用户提供非规范化的数据（比如，库存信息、单次促销金额）。

第二种：利用底层的功能来提供专门的业务逻辑（比如，先增加积分判断再去发放权益）。

 图2

我们一起，又想了想。

是，就这两种。

随着时间的推移，这两类需求会引起服务出现层级结构的分化。靠近系统边界的服务会和某些服务交互以聚合它们的输出——我们将这种服务称为聚合器；还有些专门的服务会作为协调器，来协调下层多个服务的工作。

那为什么我们的后端研发人员总是感到需求很多，那么多呢？

因为，纵然种类只有两种，但是每个种类下的需求数量，需求个数确实多，所以我们的后端研发人员非常辛苦，说需求多也是没有错误的。

有没有什么理论的方法，指导一下，改变改变么？

系统多，需求多，如果人又少的情况下，我们更应该注重建设业务中台能力。

第一步，前后端分离，前端开放出去。

第二步，聚合共性业务流程能力，个性化业务逻辑开放出去。

通过合理的成本转移，共享、共建。

我在上周思考系列文章中，画了一张图，也是在阐述这个逻辑。

 图3

只是在这个过程中，对开发人员的习惯和方式都会形成挑战，甚至有人会觉得这是阻碍他们开发，这些刚开始都是可以理解的。

OOA、OOD、OOP，常年游走在这些之外，突然又被拽到这个路径上来，难免会不舒服，甚至自己早已都忘记了OO的能力，尽管常年在用Java这样一门OO的编程语言，却一直写着函数式代码。

说到这里，有人，会发起挑战。

你说的这样轻巧，共性能力聚合、个性能力开放，就问你，一个简单的问题。

来了一个需求，你到底是在原来的服务中增加，还是新开一个服务？

好，我们还是以《微服务实战》中的一个例子来说明。

做了一个在线投资工具，用户要提交订单，然后把订单提交到交易市场交易，因此需要一个订单管理的服务。

那么，订单管理里面，就包含了记录订单的状态和将订单提交到市场两个功能。

这两个功能都在一个服务里面，我们要不要继续让它们保持现状，凡是跟订单管理相关的需求，都放到这个服务里面，还是我们需要考虑，有的需求，要新开一个服务呢？

回答两个问题。

1、驱动市场操作这个领域变化的因素是什么？

答：不同的市场规则、新开发的市场

2、驱动订单管理这个领域变化的因素是什么？

答：产品订单的类型、交易的账户

因此，你会发现，这两个领域并不会同时变化！但是，它们却放在了一个服务里面。

那么，每次来了任何一方的需求，另外一方都要被代码牵连，至少你测试的时候要都想着它们吧。

 图4

你说，需求来了，我们应该放到一个服务里面，还是新开一个服务呢？

答案就很明显了吧。

你说，怎么做能力聚合呢，共性的能力，要区分它们的修改原因，修改原因不同，则不建议把它们放到一起，可以形成多个微服务，而这些微服务又共同组成了“业务能力的聚合”。

----END----

这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。

与爱学习、爱思考、爱记录的你共勉。

我们有一个【架构基础知识学习群】已经运行三年了，每天晚上一个架构技术知识点，加我微信wangxindong2015，一起学习！

参考资料：

《微服务实战》，文中图124皆出自此处