心想技术驱动业务，却在背道而驰

这里是Z哥的个人公众号

每周五11：45 按时送达

当然了，也会时不时加个餐～

我的第「165」篇原创敬上

大家好，我是Z哥。

相信每一位真正的程序员心里都有这样一个念想：只要我的技术够牛，就能驱动业务的发展。

但是往往我们在不自觉间做的是背道而驰的事情。

业务：我希望在这个报表里多展示某个字段行不行？现在每次我都得手动把数据合并一下，有点麻烦。

技术：这个字段不在我们的系统里，要加上的话，我们需要从别的业务系统拿数据，比较麻烦，而且可能准确性和及时性都会差一些。如果非要加的话，开发工期会比较久，你需要走需求流程。

业务：啊，不是吧。多个字段显示，有这么难吗？

业务：用户反馈这个活动链接分享给他的好友后他们点开是空白的。

技术：这个活动本身是站内活动，我们没考虑会分享到站外的情况，所以这里信息校验没通过，导致页面数据没有返回给客户端，造成了打开空白的情况。

业务：其实我只想知道……现在要怎么解决？

上面的这些景象是不是很熟悉呢？

那么技术驱动业务到底是不是存在呢？答案是肯定的。Z哥我认为，主要体现在以下两个目标：

1. 解决过去无法解决的问题

2. 让解决问题的效率大大提升

但是我们仔细来思考一下这两个目标。

首先，「解决过去无法解决问题」。“过去无法解决”这六个字就已经劝退99%的人了，这里面一部分人的想法是：过去无法解决，现在肯定也没法解决，算了。另一部分人甚至完全看不到这里存在问题，因为潜意识已经默认这个问题本就是现实的一部分。

其次，「让解决问题的效率大大提升」。这几乎肯定不是小打小闹能实现的，必然要从一个新的思路来解决问题才有可能。然而，人的思维惯性会阻碍新思路的产生，很少有人可以跳脱出现有解决方案的框架来重新考虑问题。

所以真正能做到技术驱动业务的关键并不在于你的技术有多牛，而是思维能否跳脱出过去的束缚，并且要拥有业务感觉，要懂业务。因为从概念上来说，业务是“钉子”，技术是“锤子”，前者是问题，后者是问题的解决方案。

其实，先不要说能「驱动业务」，能做好「支撑业务」的人我觉得就是一位优秀的程序员了，因为要达到这点也不容易。具体可以从以下三个方面入手。

/01  理解业务/

如果你无法吃透业务，真正理解业务，那么别说驱动业务了，你能把业务实现到预期的80%都不错了，就像上面提到的第二段对话。

当然技术人员对业务的理解方式和业务方、产品经理并不完全相同。最大的区别在于，技术人员需要对业务的“不可见”部分了解更多。比如，多个环节背后的流转过程，这会影响你的技术实现和程序设计。

对于这个方面，Z哥只给你一个建议，不管你用什么方式方法来理解业务，你一定要带着： 这个业务的提出是为了解决什么问题或者实现什么目的？

要做到这点有难度，因为大家的本位意识会让你习惯于盯着开发工期、deadline这种方面。但是只要你能带着这个角度去思考，至少可以将业务实现地无限接近预期的100%。

不过，理解业务最多算是一个目标校准的工作，而且还没涉及到技术。我们要做好「支持业务」甚至是「驱动业务」的动力源还是在技术方面。

/02  稳健、可扩展的基础架构/

能够支撑或者驱动业务的首要前提，必须是你的“地基”不但稳固而且要领先于业务去规划。所以底层的基础架构设计非常重要， 如果视野仅仅关注“这个需求该怎么实现”自然达不到这样的效果 。

这一点需要提升你的软件设计意识。简单的像设计模式之类的，复杂一些的则需要你吃透一些经典的设计原则和设计思想背后的优缺点和适用场景。

常见的设计原则：

• SRP 单一职责

• OCP 开闭原则

• LSP 里氏替换原则

• DIP 依赖倒置原则

• ISP 接口隔离原则

这些设计原则都有标准的定义，我就不一一列出来了，不清楚的可以自行网上搜索。

常见的设计思想：

• 分层架构

• 六边形架构

• 洋葱架构

• 领域驱动设计

这里的每一个设计思想，都够写好几篇文章，我这里就不展开了。

/03  构建完备的领域模型/

上面的四个设计思想，要我说哪个最有用，肯定是DDD。最近几年DDD也被炒的非常火。

这里的领域模型就是DDD中的概念。

我算是国内比较早一批接触DDD并运用的人，大概在2014年的时候机缘巧合了解到了DDD，然后啃了两本最经典的书，当时给我一种看到世外桃源的感觉（真实感受，不夸张）。

它让代码里的model变得有血有肉，好像你在设计一个虚拟城市一样。这里需要摆一个物件，那么它需要长成什么样子，你要尽可能详细的描绘出来；那里需要摆一个人物，那么他长什么样子，当时正在做什么事，也得描绘出来。

DDD让你摒弃了传统三层架构以数据表为核心的代码设计方式，可以让业务含义更多地体现在代码中。如此的好处很明显，就是你的代码可扩展性必然很强，因为你的一个model体现了现实世界中所代表的对象，现实中的对象多了一种行为，那么给这个model增加一个对应的function就好。

如果你是一位DDD（ 领域驱动设计 ）新手，并对DDD感兴趣，可以翻阅我2016年写DDD系列文章 《如何一步一步用DDD设计一个电商网站》 来入门。（当时还没开通公众号，所以你得到我的博客去看：zacharyfan.com）

不过里面有些内容在后来我有新的理解，但并没有更新。 不过这不影响你体会DDD的优雅，所以你还是可以看看。

当你做好了前面的3步， 你就具备了驱动业务的前提条件。

1. 懂业务。

2. 基础架构够稳、弹性够强。

3. 现实的问题在技术维度上体现的够清楚。

在这之上你就可以尝试基于对领域模型的观察找到前面提到的技术能够驱动业务的两个目标：

1. 当前无法解决的问题

2. 当前解决效率不高地方

好了总结一下。

这篇呢，Z哥和你分享了我对技术驱动业务这件事的看法。

我认为技术驱动业务的关键并不在于技术多好，而在打破惯性思维和对业务的理解深度上。

所以，如果你想真正做到驱动业务，不妨先将以下3点基础工作做好，否则只是空想而已。

1. 理解业务

2. 稳健、可扩展的基础架构

3. 构建完备的领域模型

希望对你有所启发。

推荐阅读：

• 好的自我介绍，面试成功一大半

• 软件如何优雅地向前兼容？

原创不易，如果你觉得这篇文章还不错，就「 在看 」或者「 分享 」一下吧。鼓励我的创作 ：）

如果你有关于软件架构、分布式系统、产品、运营的困惑

可以试试点击「 阅读原文 」