业务类系统，一般包括crm、供应链、物流等，而这些系统的架构设计非常具有挑战性。文章主要跟大家分享的就是一整套业务系统产品技术架构的方法论，一起来看看~
业务类系统（通常称为ToB类产品），一般包括crm、供应链、物流等。系统的架构设计非常具有挑战性。
面向用户的ToC类前台产品，无论产品经理还是用户都已经培养起了使用习惯，对功能有一定程度的理解，见过的模式足够多，能够建立起一定的产品模型，也容易找到参照物去模仿。
但是业务类的系统，常常是没有参照和模仿，一些业务流程的不同，一点公司组织结构的不同，你家的CRM和他家的CRM可能完全没有参考性。所以在搭建产品架构的时候则要求产品经理非常懂业务，考验PM能力的同时，对技术架构也具备很大的挑战。
首先，思考一下好的产品（业务模式）是什么？
一、业务类系统，一般需要加强的三个方面
基础服务包括技术方面基础这不用多说。业务型基础服务也不要忽视，比如：城市服务、入口管理等，这些如果前期没有执行好的标准，系统一旦累计几年，将难以调整。
业务架构和数据运营，都会在后面专项的提到。重点说业务系统的架构方法。
二、技术架构的三个要素
1.三要素的顺序一定是从功能到系统，最后是架构
先说功能，功能元素指的是一系列的操作集合，能构成一个完整的功能，比如：登录、注册。
使用者通过一个功能元素完整的完成一项唯一的工作，技术上可以叫做模块，产品上称为功能。当然在产品设计和持续迭代过程里，常常很难如此实现唯一。
系统是指相互之间有直接或间接关系的功能元素形成的集合，此集合能单独为特定使用者提供特定的服务，比如：销售系统、客服系统。
我们说的技术架构，一定是“多个”独立系统之间的事情。我们开始谈技术架构的第一步，各系统必须先独立，工程和数据耦合的一起的系统，没有架构可言。没有任何关系的功能元素组成，不能称为系统。同样的没有任何关系的系统组成，不需要架构。
2.要区分技术实现方法和技术架构的不同
针对功能和系统的实现，会对应的采用DB，ES，负载均衡等实现方法。很多实现方法可能技术含量很高，但不要把和整体技术架构混淆，技术实现方法和技术架构是两回事。
3.制定技术架构，必须考虑系统功能层级
技术架构就是指把不同的功能元素（系统）放在适宜的环节、合适的层级，并且建立功能与功能，系统与系统之间关系，形成一个结构化、平台化、体验简约的大系统。
架构和功能层级表达的其实是信息之间的流转关系，不同信息层级之间一定是有逻辑关系的。各层次之间虽然相关，但同一层级的功能系统之间一定是独立的，同时客观上也常常对应着不同的技术部门和业务部门。
业务类系统的架构设计比ToC的复杂很多。
（1）按功能模块来进行划分
适合产品目标单一的ToC产品，或者单一上下游的ToB系统，系统的使用者群体单一，使用者群体单一，功能和功能之间并没有太多的逻辑关系。
（2）按业务逻辑来进行划分
适合复杂类的ToB系统，多角色共同完成一系列的工作。一个功能（系统）务必在同一层级内解决，否则容易造成信息架构被打破。
首先要总结出第一级别的功能元素，这个第一级别功能元素，其实就是我们的业务主线，也就是核心业务；线索、cc、建单、带看、成交、过户……
合格的系统，需要第一功能层级间建立合理的关系（现实原因，的确常常次要功能间，不容易建立合理关系）。
三、技术架构的两个原则
（1）说到系统架构，架构师的组织能力很重要，组织的不只是一个系统的各个功能元素，需要具备组织不同的系统的能力。在于理解要为谁，解决什么问题。
技术架构和产品架构，必须一致，各自用不同逻辑做拆分，建关系，那是灾难。
对业务整体有深刻的思考和理解，还需要更强的产品抽象能力。九成的产品经理，其实不谈产品架构。常常挂在嘴边就是业务需求，好像工作就是业务的翻译官。
（2）我们通常所谓的某产品，其实就是业务模式，就是流程和规则，如果业务系统的主流程和规则不是你设计的，只是翻译业务需求，那业务部门直接找技术也行得通。
一个产品的使命是为使用者提供特定的服务，要我们通过什么样的方式为使用者提供什么样的产品和服务。所以一定是业务导向的，以业务结果的好坏评定，一切都是为业务服务的。
所谓产品架构，还是技术架构，都是信息架构。
作为系统业务架构师，需要时刻脑子里有个大系统的产品（技术）架构图。要有能力把产品功能（技术模块）抽象成信息化的层级的架构。通过功能与功能的组合、层级关系的交互传递信息的流转，整个架构图传递的是我们的业务流程、商业模式。
产品要有技术能力，技术如果不懂产品，那再资深的工程师，也只能是码农……
这里说一下系统扩展性的问题，为最后第八章的实例做个铺垫。
好的架构各个子系统之间相互配合形成一体化平台，子系统间只有最小的重复度独立，系统各自支持不同的业务板块，多个系统作为一个整体，共同为支撑公司业务。
可扩展性其实是在传达一个信息，我们是否了解未来这个产品会有哪些哪方面的新增加功能或者内容，也就是产品规划。没有人真的能预知未来，但新增功能，新的系统都会导致信息架构重新调整和使用者的认知成本。
所谓可扩展性，就是尽可能为明天的改变降低成本，减少调整，这就需要系统架构设计是可横向共享的。而在业务系统里什么是能共享的呢？就是自始至终贯穿整个业务链条的，一般是客户、订单、商品等。所谓各系统的打通，其实就是各系统间如何有效的传递客户，商品等的信息状态。
好的架构能良好的支持业务的横向扩展。这点很重要，新的业务很多时候都在试错阶段，随时会增减业务环节，也就是不断地新的系统，新功能的融入。比如：在几个流程节点上增减一个三方部门审核操作，审核系统本身不麻烦，但要做到即插即用，对接多个系统和公司多个单位，那不同的架构可能工作量差异很大。
好的业务架构各个系统的数据在业务整体上是连续的、完整的、准确的。通过数据采集，方便建立DW，可以很好的为业务运营提供数据支撑。
好的业务架构，系统能提供的不止于业务功能，还有无时不刻无处不在的驱动各模块业务和各合作伙伴业务更好决策的数据。
四、业务系统和用户系统
以产品为中心，是我有好的市场调研，我有牛掰的产品经理，我给你的产品就是我能做的最好的，最大可能是你需要的。以客户为中心，适合面向运营单位，面向商家的企业级应用，理念是你需要什么。这里的你，可以是直接用户，商家，也可能是公司的销售，客服等。
如果不理解这个以产品为中心和以客户为中心的不同，以用户产品的思路做企业级应用，就会出发点出错，就是闹笑话。比如：我之前的公司，明明是以CRM为主的营销管理系统，但同事们喜欢拿个淘宝网站的架构来做参考。
理论上，用户系统里淘宝网站和人人车、链家、京东都是一样，都是把商品（车/房）展示给用户，获得订单（线索）。作为“信息”提供方，是把自己有的东西，用自己的方式展示出来。
理解两类系统在逻辑上的差异，我也是用了很多年，过去在公司总是和同事说不清楚，其实也是我自己没想明白。
可能是我在写这篇文章时候才多了些思考：
（1）用户产品