这里是Z哥的我的公众号程序员
每周五11：45 按时送达面试
固然了，也会时不时加个餐～设计模式
个人第「165」篇原创敬上架构
你们好，我是Z哥。
框架
相信每一位真正的程序员内心都有这样一个念想：只要个人技术够牛，就能驱动业务的发展。分布式
可是每每咱们在不自觉间作的是背道而驰的事情。网站
业务：我但愿在这个报表里多展现某个字段行不行？如今每次我都得手动把数据合并一下，有点麻烦。架构设计
技术：这个字段不在咱们的系统里，要加上的话，咱们须要从别的业务系统拿数据，比较麻烦，并且可能准确性和及时性都会差一些。若是非要加的话，开发工期会比较久，你须要走需求流程。设计
业务：啊，不是吧。多个字段显示，有这么难吗？3d
业务：用户反馈这个活动连接分享给他的好友后他们点开是空白的。
技术：这个活动自己是站内活动，咱们没考虑会分享到站外的状况，因此这里信息校验没经过，致使页面数据没有返回给客户端，形成了打开空白的状况。
业务：其实我只想知道……如今要怎么解决？
上面的这些景象是否是很熟悉呢？
那么技术驱动业务究竟是不是存在呢？答案是确定的。Z哥我认为，主要体如今如下两个目标：
解决过去没法解决的问题
让解决问题的效率大大提高
可是咱们仔细来思考一下这两个目标。
首先，「解决过去没法解决问题」。“过去没法解决”这六个字就已经劝退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步， 你就具有了驱动业务的前提条件。
懂业务。
基础架构够稳、弹性够强。
现实的问题在技术维度上体现的够清楚。
在这之上你就能够尝试基于对领域模型的观察找到前面提到的技术可以驱动业务的两个目标：
当前没法解决的问题
当前解决效率不高地方
好了总结一下。
这篇呢，Z哥和你分享了我对技术驱动业务这件事的见解。
我认为技术驱动业务的关键并不在于技术多好，而在打破惯性思惟和对业务的理解深度上。
因此，若是你想真正作到驱动业务，不妨先将如下3点基础工做作好，不然只是空想而已。
理解业务
稳健、可扩展的基础架构
构建完备的领域模型
但愿对你有所启发。
推荐阅读：
原创不易，若是你以为这篇文章还不错，就「在看」或者「分享」一下吧。鼓励个人创做 ：）
若是你有关于软件架构、分布式系统、产品、运营的困惑
能够试试点击「阅读原文」