对业务的一些思考

2022-05-31

好久没写思考相关的博客了，正好有三个和业务相关的内容可以聊聊。它们是组合商品、DDD、交接，分别和模型、架构、调整相关。

组合商品对食品、美妆的GMV提升有很大帮助。

先明确组合商品的定义：

名词	解释
组合商品	由多个子商品组合成的商品或者由一个子商品多倍组合成的商品类型
子商品	平台上的普通商品，发布组合商品时选择的商品，将作为子商品定义
组合售卖价	单品在发布组合商品过程中，设置的单品的售价，区别于商品单独售卖的价格

如洗发水和护发乳可以组合成一个商品进行售卖。

最初做组合商品的时候，交易决定不感知子商品，只感知主商品，子商品信息只做透传。这个方案的好处是交易只需要关注主逻辑，不必关注细节。

但商品终归要拆分到子商品，然后发送给用户的，这部分任务由履约进行处理。

随着业务的发展，我们发觉这种设计会带来很多问题：

1. 如果子商品在下单的时候需要动态添加一些属性，交易不感知子商品，就无法实现
2. 交易不感知子商品的一个前提是，其它部门获取交易快照，都只需要主商品，不需要子商品。一旦需要感知到子商品，各个组需要自己拆解，无形中增加成本

综上所述：

1.采取何种模型，一定要做好推演，需预判目前的模型能否满足未来的业务需求

• 此处经验极其重要
• 采用某种方案，一定不能以开发方便为准则。因为后期改动成本远高于一次做好

2.个人认为，如果自己是处理某个问题的起点且是各个组依赖的中心部门，最好能包掉这些差异
3.如果新的功能点引出新的模型，这是特别好的机会，一定要设计好新模型，并和已有模型做好融合

DDD这两年很火，但没有完全推广起来。以前看过两本DDD的书，领域驱动设计精简版和领域驱动设计：软件核心复杂性对应之道。我建议使用DDD，因为随着业务越来越复杂，使用传统模式很难应对快速变化的业务。但DDD的学习成本很高，需要不断的去实践、去感受。大家如果有机会，还是尽量去尝试。

可以从两个方面理解DDD，一个是从系统设计上，一个是从理念上。

• 在系统设计方面，建好各个领域，并不断做重构

• 在理念上，需要明白什么是自己的核心域，要敢于做好取舍

之所以聊这个话题，是因为我发现部门A对DDD有较深的理解。说来也有些搞笑，和A组合作一个大项目，技术方案已定，但开发前说有变动。

变动也不大，我们作为调用方，本来A组会提供很多包好的接口，现在不提供了，只提供基础能力，即RPC接口，API层的接口需要我们单独开发。

我理解这么选择的原因，因为A组

1. 开发人员数量和支撑的业务数量不匹配，活太多人太少
2. 业务快速变化，很难在应用层梳理出共性的内容，处理不好会进一步加剧问题1

所以他们选择将重点放到模型建设上，确保模型是可用、可扩展的，至于上层业务，谁用谁组装。

好处很明显，一是能够做到收敛，气力都花在刀刃上，不被俗事所扰；二是可以有更多的时间锻炼好内功，解决技术债，给团队指定新的基调；三是成员能在更高的维度上成长。

坏处就是业务组需要自己多些开发量，不同业务可能存在重复开发的可能性，但这个影响总体还好，因为这也意味给业务方提供了更多自主权，开发效率未必会低。

我很赞赏A团队解决问题的思路：确定基调、保证实施（强硬）。这两步走起来都不容易，确定基调说明找到了解决问题的核心点，尽管这个基调和团队以前的职责范围不太一致。保证实施则是需要坚持和勇气，好在是兄弟团队，大家相互能够理解和支持。

不过感觉随着内功练好，最终还是要上移到应用层，收敛出通用业务模型，这样才能进一步扩大影响。

几个月前因为组织架构调整，将一些项目进行了交接。我支持交接，因为合理的交接能够帮助业务更快速的发展，从整体上看，大家都能受益。

对于很明确的项目，直接交接即可。但存在部分业务，处于中间状态，是否需要交接判断的依据是什么呢？

到现在我还是没完全想明白标准是什么，不过中间做了一些项目，有一些相应的思考：

1.需求会出自哪里？

• 如果完全来自其它团队，那最好直接交接。任何产品都有长期规划，产研不在同一个team，会很绕
• 如果需求大部分来自对应的产品团队，那就不应该交接
• 如果需求可能来自对应的产品团队，也可能来自其它团队，可以问一下产品对该模块有什么规划，如果有详细的规划，也不要交接

2.项目价值是什么？项目与主航道相符吗？

• 这需要自己对项目价值、对今后主航道有较深的理解。无论是个人还是团队，精力都是有限的，需要将精力放到价值最大的事情上
• 如果价值低、与主航道不相符，最好交接

3.是否能提升效率

• 完整的功能模块，能全部交接就全部交接。如订单进行履约操作，需要给服务商推送订单、从服务商接收各个订单节点的通知。这种功能要交接的话就一起交接，因为分成两部分没有好处，可能出现顺序错乱问题、系统出问题两边都要查、做全流程数据监控也需要从不同位置获取数据，并不能带来效率提升

交接还是蛮考验对业务理解的深度的。当然如果一些模块没有想好，可以先不交接，根据后续需求情况，慢慢就知道如何选择更加合适，自己想明白了再处理也是可以的。