方法论：业务系统的技术架构

好的架构能良好的支持业务的横向扩展，各个系统的数据在业务整体上是连续的、完整的、准确的。业务系统的技术架构如何搭建？文章围绕这个问题展开了详细的说明，与大家分享。

业务类系统（通常称为To B 类产品），一般包括CRM，供应链，物流等。系统的架构设计非常具有挑战性。

面向用户的To C 类前台产品，无论产品经理还是用户都已经培养起了使用习惯，对功能有一定程度的理解，见过的模式足够多，能够建立起一定的产品模型，也容易找到参照物去模仿。

但是业务类的系统，常常是没有参照和模仿，一些业务流程的不同，一点公司组织结构的不同，你家的CRM和他家的CRM可能完全没有参考性。所以在搭建产品架构的时候则要求产品经理非常懂业务，考验PM能力的同时，对技术架构也具备很大的挑战。

首先，思考一下好的产品(业务模式)是什么？

一、 业务类系统， 一般需要加强的三个方面

基础服务包括技术方面基础这不用多说。业务型基础服务也不要忽视，比如城市服务，入口管理等，这些如果前期没有执行好的标准，系统一旦累计几年，将难以调整。

业务架构和数据运营，都会在后面专项的提到，重点说业务系统的架构方法。

二、技术架构的三个要素

1. 三要素的顺序一定是从功能到系统，最后是架构

先说功能，功能元素指的是一系列的操作集合，能构成一个完整的功能，比如登录，注册。

使用者通过一个功能元素完整的完成一项唯一的工作，技术上可以叫做模块，产品上称为功能。

当然在产品设计和持续迭代过程里，常常很难如此实现唯一……

系统是指相互之间有直接或间接关系的功能元素形成的集合，此集合能单独为特定使用者提供特定的服务，比如销售系统，客服系统

我们说的技术架构， 一定是“多个”独立系统之间的事情。

我们开始谈技术架构的第一步，各系统必须先独立，工程和数据耦合的一起的系统，没有架构可言

没有任何关系的功能元素组成，不能称为系统。同样的没有任何关系的系统组成，不需要架构

2. 要区分技术实现方法和技术架构的不同

针对功能和系统的实现，会对应的采用DB，ES，负载均衡等实现方法。很多实现方法可能技术含量很高，

但不要把技术实现方法和整体技术架构混淆，技术实现方法和技术架构是两回事

3. 制定技术架构，必须考虑系统功能层级

技术架构就是指把不同的功能元素（系统）放在适宜的环节、合适的层级，并且建立功能与功能，系统与系统之间关系，形成一个结构化、平台化、体验简约的大系统。

架构和功能层级表达的其实是信息之间的流转关系，不同信息层级之间一定是有逻辑关系的。

各层次之间虽然相关，但同一层级的功能系统之间一定是独立的，同时客观上也常常对应着不同的技术部门和业务部门。

业务类系统的架构设计比ToC的复杂很多。

（1）按功能模块来进行划分：

适合产品目标单一的ToC 产品，或者单一上下游的ToB系统，系统的使用者群体单一，使用者群体单一，功能和功能之间并没有太多的逻辑关系

（2）按业务逻辑来进行划分：

适合复杂类的ToB系统，多角色共同完成一系列的工作

一个功能（系统）务必在同一层级内解决，否则容易造成信息架构被打破

首先要总结出第一级别的功能元素，这个第一级别功能元素，其实就是我们的业务主线，也就是核心业务。 线索，cc，建单，带看，成交，过户。。。。。

合格的系统，需要第一功能层级间建立合理的关系（现实原因，的确常常次要功能间，不容易建立合理关系）

三、技术架构的两个原则

（1）说到系统架构，架构师的组织能力很重要，组织的不只是一个系统的各个功能元素，需要具备组织不同的系统的能力。在于理解要为谁，解决什么问题。

技术架构和产品架构，必须一致，各自用不同逻辑做拆分，建关系，那是灾难。

对业务整体有深刻的思考和理解，还需要更强的产品抽象能力。

九成的产品经理，其实不谈产品架构。常常挂在嘴边就是业务需求，好像工作就是业务的翻译官

（2）我们通常所谓的某产品，其实就是业务模式，就是流程和规则，如果业务系统的主流程和规则不是你设计的，只是翻译业务需求，那业务部门直接找技术也行得通。

一个产品的使命是为使用者提供特定的服务，要我们通过什么样的方式为使用者提供什么样的产品和服务。所以一定是业务导向的，以业务结果的好坏评定，一切都是为业务服务的

所谓产品架构，还是技术架构， 都是信息架构。

作为系统业务架构师，需要时刻脑子里有个大系统的产品（技术）架构图。要有能力把产品功能（技术模块）抽象成信息化的层级的架构。通过功能与功能的组合、层级关系的交互传递信息的流转，整个架构图传递的是我们的业务流程、商业模式。

产品要有技术能力，技术如果不懂产品，那再资深的工程师，也只能是码农。。。。

※ 这里说一下系统扩展性的问题，为最后第八章的实例做个铺垫。

好的架构各个子系统之间相互配合形成一体化平台，子系统间只有最小的重复度独立，系统各自支持不同的业务板块，多个系统作为一个整体，共同为支撑公司业务

可扩展性其实是在传达一个信息，我们是否了解未来这个产品会有哪些哪方面的新增加功能或者内容，也就是产品规划。

没有人真的能预知未来，但新增功能，新的系统都会导致信息架构重新调整和使用者的认知成本。

所谓可扩展性，就是尽可能为明天的改变降低成本，减少调整，这就需要系统架构设计是可横向共享的

而在业务系统里什么是能横7共享的呢， 就是自始至终贯穿整个业务链条的，一般是客户，订单，商品等。所谓各系统的打通，其实就是各系统间如何有效的传递客户，商品等的信息状态

（编辑：ASP站长网）