不写单元测试的码农不是好的厨师，哪怕您只想撸一生增删改查，可能公司也不允许。现实公司，多数同学还是业务开发，业务开发往上一个台阶，很容易想到业务架构师，今天我们来聊聊业务架构。
公司/业务
实际上，所有公司都有一个最本质，最底层的需求：活下去。
活下去，就需要盈利。那么，一家公司是怎么盈利的？创造什么价值？提供什么产品？目标客户？渠道？上下游？整个业务链路是什么？
在这个基础上，把我们负责（或者即将开发）的系统套进这个大的业务链条中去思考。我们负责的系统，占据什么样的位置，和其他系统怎么交互，如何影响和干预最终的结果。 这才是真正的“业务”。
以常见的电商公司的订单系统为例，订单系统，上游必不可少有购物车，有支付,营销，商品，价格。订单是是履约的基础，下游有物流，财务，如果是自营，和仓储管理系统之间也会有交互。
如果你没思考过这个问题，从现在开始也不晚，先从宇宙公司的中台战略开始。
恰如其分地设计
不存在的。这是一场产品经理+项目经理和架构+开发的战争，好的架构师要活下来，必须通晓业务，不求熟悉到具体逻辑细节，但是上一节的内容我们得做好，要充分理解系统的定位，上下游，输入输出，交互，识别核心/非核心业务，方有胜算。
产品经理比我们更清楚业务的具体问题，痛点，但是他们通常只会抛出问题的解决方案，而非问题的原貌。当解决方案不合理时，可能引导我们错误/过度设计。我们得有依据怼产品，依据就是我们也懂业务，更懂实现的细节。
另外一个问题是，过度设计几乎不可避免。凡是有架构经验的开发，遇到一个新的功能，第一件事就是脑补以后可能出现的其他场景，全部预留设计。预留设计可能带来的问题是，增加系统复杂性，开发量增加，延迟上线或者加班。而针对这个问题，比较合理的解决方案，也只有一个，就是做好上一节的内容，清晰理解业务（核心/非核心），对其中可能变化的部分预留设计，对相对稳定的部分粗暴处理，平衡进度和设计的冲突。
平衡/决策
架构 = 可读性 > 性能
架构的合理，其实和代码的合理很类似，高内聚，低耦合，可扩展。
系统的可读性，这个概念比较少听到，先当成我发明的。什么意思？就是系统的边界，可扩展性，复杂度要控制在一个合理的范围。
其中一个原因是，过于复杂的系统通常没有好下场，后面重构的人看到只会吐槽而不想动，也会提高客户的学习成本，运维的复杂度。如果系统内太过复杂，考虑抽象一层，一个系统不够就两个（没有什么问题是加一层解决不了的）
好的代码，不用注释也能看懂，结构清晰，封装合理，最复杂的逻辑仅仅是存在某些业务方法的实现里面，方法描述和方法实现分离，我们关注的是描述，关系的合理。好的系统设计也该如此。
性能是一个误区，有些老司机会过于追求性能，放弃架构的合理和可扩展性。通常来说，具备可扩展性的系统，通过水平扩展可以处理性能问题，当然在特定场景，比如说11.11，为了极限的性能放弃部分合理设计，也有合理性。实际上大多数性能问题还扯不上架构，关键把SQL稍微优化做好就完成了大部分工作，具体可出门向左转，看看MySQL语句的优化。
架构，其实就是一个决策，平衡的过程。比方说涉及资金支付的系统，性能的重要性远远不如安全，健壮。如果是日志或者监控系统，那适量丢消息并不是大问题，总体性能更重要。
技术积累
这个必不可少，视野内的，通过一小段时间学习能掌握的技术，是技术选型的最大范围。视野决定上限。
不只是写代码才是技术，了解系统的全面认知，对业务的上下游的理解和掌握也是技术活。视野来自于你的要求，对自己的要求决定你的上限。
有图有真相
最后，请把你的积累沉淀在wiki，xmind，visio上，记录下来，哪怕只是一个小功能的输入输出的数据处理流程，把里面的组件替换成模块，和系统交互图差别已经不大了。
关于作者
热衷于教产品做人的开发者，加班夜不归宿的重度脂肪肝患者.
