一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第2天，点击查看活动详情。

画外音：

一直都在收拾了别人的烂摊子，总结一下怎么做一个"人见人夸"的功能设计。

这个系列主要写给产品看，最佳实践不敢说，失败案例我有大把可以分享和吐槽的。

研发请随意，有不妥的地方欢迎指正。

前情提要： # 为什么你的轮子很难用（一）：别造，造的话先盘组织和业务

当你不得不造一个轮子的时候，你需要先储备一些基础常识。内容很多，我们分期讲：

一、战略问题

DDD很火，但说实话，实操性一般，业内也没太多最佳实践在吹。

问题出在哪呢？出现得太晚，积重难返 且 CTO 乃至CEO 无心 或 缺位。

毕竟行业或者赛道都衰退了，现金流都不行了，谁有心思搞这个。

所以

第一件事情：判断 大搞 还是 小搞

找几个靠谱老同事问问，这个业务还能风光几年。

按最大30%的时间，估计 你可以投入的时间和人力。

三个月以下 统称小搞。半年起步，中搞。2年以上 大搞。

30%是个人经验参数，仅供参考。

第二件事：搞什么

根据你前置判断的资源：时间和人力。

写一写 这个轮子要承担什么？ 商业术语叫 “企业任务综述”。换个object罢了。

业务方面——盘过去：

对接几个业务方，主要面向什么场景？（ 延伸问题：什么条件能判断，这个场景你不该接？）

要实现出来什么效果？对比行业竞品有什么优势？怎么评价TA是有效的？

技术方案——想未来：

在全公司or 业务内处于哪一个分层？同层服务有哪些？是否需要聚合，拆分？

要沉淀什么能力，对于未来什么业务场景有落地价值？

（这个地方的服务，不是soa的服务，是 系统乃至中台层面的 服务能力）

回答清楚以上问题，再回过来想想，还要大搞吗？

第三件事：想驱动

这个需求什么驱动范式比较好呢？

产品or业务驱动？产品是能当半个架构师SE的角色深入配合实现？还是指挥他画原型写API文档？

前端/客户端 驱动？这个轮子重操作交互编辑体验吗？需要有个产品吗？（回归第一问）

后端驱动？测试或者其他团队怎么介入做 黑/白盒测试联调呢？需要有个前端吗？（回归第二问）

第四件事：业务功能层的抽象

每个业务都需要什么功能，把典型用例遍历一下。

面向过程研究一遍，每个用例都有什么共性的case？

拆拆拆，再并并并。

从拆到并，就实现了 面向过程，到面向切面的转换。

当然不能无脑并，这个时候要考虑的东西有点多，包括但是不限以下内容：

1）并之后，原有的业务逻辑 有什么优化和提升吗？节省了什么成本？

2）后续拓展怎么办？如果你是业务方，你会想出来什么稀奇古怪的关联（调用）呢？

有多少是现成能跑通？有多少是需要单独再做的（包括不限于 再次封装和中间包一下）？

后面继续做一下会不会很恶心？

3）3年以后 新人（以校招生为假想），他能快手上手不用看文档就能懂，能改吗？

4）需不需要加一些强约束，避免以后被人魔改，玩烂了呢？

这里可能要加个案例，比较好理解这种纠结：

比如说常见的积分，如果你专门拆分，抽象一个积分服务，会出现什么问题？

都要跑去另外一个admin创建个积分？差评，开放给别人服务端创建。

抽奖次数和积分不是一样的中介数值吗？区别只是 积分:次数是不是1:1，

要不 次数和积分合成一套逻辑，这样过期逻辑全部都能复用了。

关联场景是 次数/积分抽奖和积分兑换？谁都能发积分，谁都能用积分？

那TM是多对多逻辑？要不还要是加个日志记录一下加减的调用明细？

单个积分业务，只能在A/B/C范围内使用吧？要不改成 一对多，放我这强校验？

校验做不做呢？谁来配？塞在哪？要不还是多对多？风险可控吗？

万一有bug，回滚起来怎么办？ ......

基于你考虑出来的点，再次调整你的 抽象逻辑。然后再反复来几次。

根据你的时间和人力，再次判断一下 吃不吃得下。

走完以上，基本就可以进入产品层抽象阶段了。

这些都是开放性的问题，很烧脑很好玩。只可惜"敏捷"让大家在方案设计上都不怎么花功夫了。

至于产品层怎么玩，欢迎订阅收看下一期：

为什么你的轮子很难用（三）从战略到抽象 2