谈业务技术的技术含量

前言

很多人都觉得前端业务研发程序员层次低，难度小，复杂逻辑都是后端的。
业务技术的技术难度提现在哪里？
往往，业务所面临的复杂性来自不断变化的需求。
或许经历过，有多角色，多业务场景，多逻辑验证，多阶段确认的需求，你才会有所体会。

场景

这里最核心的是 货物的上下架流程。
这里涉及到的有

• 人员类型：配送员、入库员、分拣员、上架员，还有小队长、中队长、大队长。
• 条码类型：运单、运单包、货架号。

注。这里的角色类型会经常发生变化，同一人可以身兼多职。

这里我用其中做过的一版：角色版。来说明

过程分解

像这种复杂程度的业务，我们肯定不会想着把业务逻辑都放在一起。

业务分解，分而治之
在这里，我们自然就会想到几种方案：
pipeline管道流：基于货物本身的逻辑，下一步应该做什么.

这种方式，会引入额外的复杂度；割裂代码，导致阅读不畅。所以，这种方式，我放弃了。
业务抽象抽离：保持KISS原则。职位决定工作内容。我采取了这种方式。

回到问题本身，我需要对货物的状态进行记录，最核心的事情，其实就是扫码。

业务开发最核心的问题：是如何分解问题和抽象问题。

货物的流转是有向的，部分状态是无法做某些操作的。
不需要关心货物流转的状态，只需要关心货物当前的状态。
而对于小队长、中队长、大队长，选择某个角色，响应的切换到对应的功能就好。

按照这样分解，复杂的状态变化不需要考虑，内容清晰明了。

需要pipeline流程吗？不需要。需要详细的考虑各个状态吗？不需要。
对于这种业务流程，找到一个合适方法，就可以大大的简化业务逻辑。

因此，在做过程分解中，我们不需要将太多精力放在工具上，放在新技术应用上。
多花时间去分析问题，结构化分解，通过合理的抽象，大幅简化业务复杂度。

分解后的思考

这样做，确实大幅简化的业务逻辑，代码结构也清晰了，更容易维护了。
但这里我们很容易忽略两个问题：

一、领域对象被切割

参与业务的不同Use Case的业务角色和业务实体时，可能会发现某些对象如此相似，甚至可以归为一类，或者可能相似到足以被视为一个相同实例的程度。
如果是这种情况，您应该将相似的类合并在一起。这就产生了一个业务角色或业务实体，它拥有足以满足不同业务用例要求的关系、属性和操作。
Use Case只关心自己的处理流程，是简化，但却缺乏沉淀。

二、业务代码的表达能力缺失

Use Case只完成了一项工作，在本文的范例中，我们抽离了 人员角色，建立了一种 业务模型。
但很多时候，我们会缺失这种模型，以及模型之间的关系。
没有模型的业务表达，是缺少灵魂的。

比如：配送员 接了小b一堆商品配送。葡萄、梨、荔枝、香蕉、鱿鱼干、饼干。
如何建模呢？
我们分析，它们有没有共性？葡萄、梨、荔枝、香蕉属于水果，鱿鱼干、饼干属于袋装零食。而在水果中葡萄和荔枝属于不宜保存水果、香蕉不能进冷库，通过这样进一步的分析得出如下的领域模型：

果品进销存领域模型

这个领域模型不但能反映当前的实体，同时给我们需求分析人员和系统功能提供了更大的视野：冷库短期保持水果，利润如何？商品如何配送？是否需要冷链？我们的冷链食品是否有盈利？这部分业务是否应该开展？

过程分解+对象模型

所以，写这种复杂业务应该是两个方向

• 自上而下结构化分解
• 自下而上建立对象分析

上下结合

优秀的模型应该是 自上而下过程分解和自下而上面向对象分析 相结合产出的。
这个过程，必须是动态的，不断迭代更新的。

• 模型提升业务表达能力；
• 分解帮助理清模型间的关系

重构：改善既有代码设计

做过代码重构，或者学过代码重构的人都知道。
代码重构总结就两招：
一、提供公共部分
二、剥离独立部分

至于是上移到何处，还是下沉到哪里，如何确立粒度化的程度，功能有没有恰到好处的内聚到某个实体上，有没有放在合适的层次上。
就需要业务人员好好的去雕琢。

业务技术人员面对的问题域变化很多、面对的人也更多。丝毫不亚于底层技术人员。

说业务技术 简单的人，是把业务给写简单了。

作为技术人员，分解问题的能力、抽象能力、结构化思维、工匠精神、思辨能力，持续学习精进，不断突破自我。
才能将代码写的越加精进！