业务系统技术架构难做？知道这三点，你会更得心应手_不考虑性能怎么做一个好的业务架构-优快云博客

前段时间看了一篇《方法论：业务系统的技术架构》的文章，里面阐述了一些做业务系统架构的原理与方法，本人甚为认同。现做一些归纳与总结，分享给大家。

业务系统一般指企业的To B系统产品。业务系统的组织形式与企业的组织架构、业务流程等有着非常紧密的联系。因此虽然业界会有一些做得很好的业务系统，但是如果照搬这些业务系统却不一定能提升你公司的业务水平，甚至可能会带来灾难。

虽然不能照搬业务系统，但是业务系统背后的架构设计思想却是可以照搬的，这些设计思想是通行的方法论，能够在高层次上指导我们进行业务系统的架构设计。

技术架构三元素

要能看透事物的本质，我们就需要将事物进行不断的分解，直到其最基本的组成元素，这样才能从根本上解决问题。

技术架构也一样，有着最基本的组成要素。技术架构有三种元素，分别是功能元素、系统、架构。

功能元素，指的是一系列相关的操作的集合，通过一个功能元素可以完成一项工作或任务。功能元素也就是我们常说的功能模块。

系统，是一堆有着各种直接或间接关系的功能元素的组合，通过这些功能元素的组合可以对外提供一套特定的、完整的服务。系统体现的是功能元素之间的关系。

架构，将多个相互独立的系统结构化地放置到合适的层级并互相建立关系，最终在更高层次上形成一个更大的系统。

三个元素还能互相转换。某个架构可以只是一个更大的系统中的“系统”，甚至是“功能元素”。

相互独立是元素、系统、架构中的一个重要特性。元素与元素之间应该是互相独立，各自唯一的，如结算功能与支付功能。系统与系统之间同理。如订单系统与客服系统。但是实践中我们会发现很难完全做到互相独立，各自唯一。也许开始进行架构设计时做到了，但随着不断的迭代，往往会出现一些独立性减少，出现重叠的情况。不过我们依然需要在设计时尽量做到互相独立。

技术架构的两个原则

业务系统是为特定的使用者提供服务，满足其工作需求，进而让公司的业务运转起来，实现商业目标。业务运转起来后是否流畅、是否高效、业务结果是否正确等等，这些都是可以反过来判断产品是否好的指标。所以技术架构的第一个原则是：服务于业务模式，以业务模式为导向。

以业务为导向要求我们在做业务系统技术架构时需要为业务模式制定合适的流程和规范，并且留有足够的扩展空间，以便应对将来面临的业务变化调整。

说到这里，可能会有读者提出疑问：做业务系统技术架构时需要为业务模式制定合适的流程和规范，这么像是更像是产品设计而不是技术架构？

这里其实就是接下来要说的第二个原则：产品架构≈技术架构。

技术架构可以说是产品架构的技术体现，技术架构应该反映出业务信息的流转、业务规则、业务模式等，并且将其抽象成结构化的组织形式。不懂产品架构的话，其实是做不好业务系统的技术架构。技术架构与产品架构的分离和不一致很容易会导致业务运行时的灾难。

感知业务结果

什么是业务结果？业务结果分两种。第一种就是用户使用的结果。

我们的用户是怎样使用我们的系统？通过使用我们的系统得到了什么结果？上一版的升级后，用户的使用效率提升了多少？每天用户通过我们的系统产生了多少业务数据？这些都是我们需要关系的业务结果。我们既需要知道怎样通过业务系统去满足用户的需求，也需要知道业务系统帮助用户得到了怎样的业务结果。

第二种业务结果则是业务系统的运行状态。我们在做技术架构时就需要考虑对系统运行状态的监控，当业务系统出现异常时，我们需要第一时间知道，而不是等用户过来告诉我们系统出了问题。这里说的监控系统运行状态不只是包含对系统是否正常运行的监控，同时也要包含对由系统生产的业务数据的状态的监控。例如发票系统的实时开票量突然出现下降，但发票系统本身却没有任何异常时，那很可能就是上游系统出现问题。虽然不是发票系统的问题，但是存在对用户使用体验造成影响的风险，这些也是需要第一时间知道并采取措施的。