最近硅谷裁员的新闻沸沸扬扬，真是让传说中程序员的天堂都“感受到了寒气”。
先是Facebook裁员，再就是elon musk收购twitter后大肆裁员。
再加上国内的形式也不好，大厂小厂纷纷裁员。
似乎程序员这个职业已经到了穷途末日。
但是，与之形成强烈对比的是，当前数字化浪潮下，各大传统企业进行进行企业架构规划，邀请了很多专家型人才去授课，出名一些的人可以按照五万每天收费。
1
专业化生存
在程序员这个行业，似乎天生就伴随着35岁危机，久其根本原因，是因为开发技术虽然更新迭代较快，但是在一个领域耕耘5-10年后，几乎可以完全独立承担工作任务。
但是，新人经过一段时间的培养也行，尤其是在架构设计体系成熟的情况下，很容易上手，而多个新人的薪资可能才赶上一个老人。
所以从财务成本考虑，各个公司都在“向社会输送人才”。
这里有一个根本的问题，很多程序员的技能是可以通过时间去积累的。
换一种说法，工作技能压根没什么门槛，靠的是“时间”线性积累的精力。
甚至可以说，绝大多数人压根没有核心竞争力。
数字化浪潮下，信息技术越来越成熟，无数的成熟工具软件，对于低端开发人员的水平要求是下降的，门槛越来越低。
那么很容易就形成了红海竞争。
如果经济向好，行业处于发展期，可能因为需要提升生产力总量，所以一般没有危机。
但是，一旦市场进入存量时代，各个行业需要精耕细作，就不再需要这么多的“工具人”了。
毕竟，“生产力”已经过剩。
而在这种情况下，对于绝大多数人来说，唯一的一个出路就是：专业化生存。
什么叫做专业化生存？
就是说，你最好成为某个领域的专家，形成你自己不可替代的核心竞争力。
什么是核心竞争力？
就是你独特的知识、技能与经验的组合。
绝大多数的技术岗位，开发技能预期说是能力，不如说是一种信息，因为所有人都可以随着时间“熟能生巧”，毕竟绝大多数工作的难度，根本用不着多么高精尖的技术，只要智商一般在线就好。
如果所有人都可以习得，那么很显然，这种能力就不能作为你的门槛。
但是你可以扩展你的能力维度。
千万不要只有一个开发能力维度。
尤其是可以叠加：垂直领域维度。
因为你的项目经验，是独一无二的，一旦和开发能力结合起来，绝对会产生乘法效果。
例如你是金融业技术人员，既懂架构技术，又懂金融业务，甚至还有项目管理技能等等多个维度能力，那么你就形成了一个独一无二的竞争力，尤其是在金融科技领域。
当然，可以提升自己竞争力的维度非常多，对于开发人员来说，效果最好的一个就是：懂业务。
那么，对于开发人员来说，到底什么是：懂业务？
2
懂业务的误区
在厘清对于开发人员来说到底什么是懂业务之前，我们先厘清两个比较普遍的理解误区。
懂了系统间的交互流程就是懂业务
很多开发人员经常误认为，自己懂所有科技系统的流程时序，知道如何进行数据串接，所以自己比业务同事更懂业务。
实际上，这只是一小部分知识，甚至可以说是边角知识，真正的业务领域专家不屑于懂。
为什么？
因为这种应用层的服务编排，实际上是因为当前的组织情况与系统存量，而设计出来的技术交互而已。
换个公司，就变了。
当前组织的这个功能的流程，顶多起到辅助编排功能。
懂业务就是去“抢”业务条线同事的饭碗
还有很多人，认为懂业务就是去完全做业务的事，将自己的长处“技术”能力，给抛弃了。
这不是典型的“以己之短攻彼之长”嘛。
技术与业务，从来不是二选一。
从上一节讲过的增强自己竞争力的视角，是两个可以叠加提升核心竞争力的能力维度！
3
懂业务的模型
之前的文章，也介绍过懂业务到底是啥含义。
但是最近很多人的咨询，让我发现，不给出一个具体的边界与模型来，大家还是搞不懂，没有路径去遵循。
所以，笔者尝试总结一下自己理解的开发人员懂业务的模型。
开发人员都熟悉的一个设计原则是：关注点分离。
主要就是说一次只关注系统的某一个方面，多个关注点会组成一个完整的系统。
但是，我们需要更进一步，封装变化，追求半衰期长不变的核心。
这个懂业务模型如下：
核心——不变的业务知识
这个业务知识一般不会频繁变化，非常稳定，不会因为组织的变化、系统架构的变化而变化。
你可能直接能从教科书上面获取到这方面的知识。
例如，对公账户开户业务，其核是对公账户的性质，基本户、一般户、专用户、临时户？
是账户的组成属性要素，例如户名、账号等等。
以及这个业务本身的功能、适用边界、适用客群，基本原则等内容。
不考虑其技术实现。
内圈——三方面知识
首先，应该是业务处理流程。
这一步我们在进行产品设计的时候，就是从业务流程开始的。
包含了一些必须的业务处理流程、节点，以及节点的作业内容。
其次，是科技处理流程。
这一块是开发人员了解系统现状，进行工作，甚至进行流程优化重构的必须点。
最后，是政策法规约束。
例如，对公开户一些政策法规的要求，必须进行上门实地尽调，等等。
这一些内容，可能随着技术的发展、经济的发展而改变。
外圈——未来可能性
首先，技术趋势。
对于科技人员来说，首先是了解技术趋势，可能重塑内部业务流程，增强客户体验。
例如，OCR识别功能可以减少客户自己填写的麻烦，也有一些大数据技术例如RPA减少运营作业工作。
其次，是政策趋势。
一些政策监管要求，可能会导致整个业务流程的变化，例如消费者信息保护就要求对于客户数据的使用进行授权。
例如，放开了二类户、三类户的开户。
第三，是市场趋势。
例如，一些银行可以进行银银合作，一些三方支付公司有了自己的三方支付账号。都会对开户业务造成冲击。
第四，是组织趋势。
组织内部如果有变动，可能会影响业务处理流程，这里不再展开。
再向外，应该还有产品思维、数据思维等等内容。
如果学习一个业务，可以从这几个人方面，从内到外的学习。
3
为什么开发人员要积极应用DDD领域驱动开发
我们上面的懂业务模型，已经讲了要关注的重点是不变的“核心”。
这也是DDD推崇的理念，一定要重点关注核心业务领域，封装可复用的业务领域知识。
而应用层，一些服务的组织编排，这种流程性的东西，一般受限于组织当前的情况，随时可变，换个公司就不一样了。
所以，开发人员去学习业务，除了根据上面的模型去学习外，最好可以推动自己负责的应用架构按照DDD的方式演进。
这样，在工作中就天然的要求开发人员去关注核心业务，而不是边角料。
请一定避开过于追求技术难度的误区，技术的价值一定是通过业务价值来体现，毕竟“技术性”含量高的工作，业务价值可能并不高。
原文始发于微信公众号（架构突围）：再论开发人员懂业务，以及之所以强烈推荐DDD领域驱动设计
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/170126.html
