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

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

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

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

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

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

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

业务架构和数据运营，都会在后面专项的提到

重点说业务系统的架构方法

 

二、技术架构的三个要素

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

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

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

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

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

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

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

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

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

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

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

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

技术架构就是指把不同的功能元素（系统）放在适宜的环节、合适的层级，

并且建立功能与功能，系统与系统之间关系，形成一个结构化、平台化、体验简约的大系统。

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

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

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

• a.按功能模块来进行划分 –

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

• b.按业务逻辑来进行划分 --

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

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

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

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

 

 

三、技术架构的两个原则

 

 

 

1 . 说到系统架构，架构师的组织能力很重要，组织的不只是一