对业务的一些思考

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

组合商品

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

先明确组合商品的定义：

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

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

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

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

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

综上所述：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）

我的个人博客为：shidawuhen.github.io/

往期文章回顾：