抽象出通用的企业级应用架构

通过对企业级应用架构进行分层，可以更好地体现其特点和逻辑结构，我们来看一下各层的含义。

第一层是对外系统 。所有供企业外部客户使用的系统都在这一层，包括官网、普通用户或客户使用的C端系统。如果是类似美团、天猫这种平台性质的企业，对外系统还会包括给商家使用的商家端。这一层的系统处在与客户接触的最前线，是公司实现商业模式的桥头堡。

第二层是与C端系统对应的管理后台 。常见的管理后台都包含订单、会员、商品等模块。每个C端业务形态都会对应一个管理后台，有些管理后台的模块可能会被抽象为公共服务，下沉到第五层，例如消息中心、订单、商品、营销等模块。

第三层是业务单元支持系统 。绝大多数业务的开展都不可能只靠线上的运作来实现，而要包含电话销售、客服、地推、仓配等一系列业务单元共同协作。业务单元的运作需要强大的系统支撑。

第四层是职能单元支持系统 。企业发展到一定规模后，必然会有完善的职能单元作为后勤部门，来支持业务单元的运转和企业的正常运作，例如法务、财务、人力部门，每个部门工作的开展都需要相应系统的支持。

第五层是基础服务支持系统 。信息化建设达到一定程度后，企业有必要将通用功能服务化、平台化，以提升服务效率，保证应用架构的合理性。这类系统主要给其他“应用系统提供基础服务能力支持。目前非常火热的中台理念，实际上就是类似的思想。

第六层是数据底层和应用 ，和第五层类似，这一层主要聚焦于数据层面的统一和封装，对各个下游系统提供数据服务。大数据平台也可以和数据仓库（Data Warehouse）并列，同属于这一层。

理解一个简化版的、典型的企业应用架构，对于准确、快速地理解、掌握、设计任何复杂应用系统架构都非常有帮助。

不同发展阶段的互联网企业的应用架构畅想

1.初创企业的应用架构畅想

2.成长型企业的应用架构畅想

3.成熟企业的应用架构畅想

企业级应用架构设计的建议

1.业务定位和边界要清晰

一套应用系统是为了解决某一类业务问题而存在的，对应某一个业务模块。如果业务部门本身权责定义混乱，必然会导致对应的应用系统定位混乱，进而导致后续的维护、升级、管理困难。因此，在设计业务系统之前的业务调研（详见第4章）非常重要，如果发现不合理的地方，需要和业务方一起确认、梳理清楚，再开始设计。

2.系统要实现松耦合、高内聚

业务的需求是在不断变化的，这要求应用系统是灵活、可扩展的。一个扩展性强的应用系统，对外界来说，应该是简单、易理解的，与外部系统的接口应该简明、可拆解；在系统内部，各个模块应该是高度聚合的，模块之间要实现松耦合，什么意思呢？可以借助汽车来理解：系统的各个模块就像汽车的轮子、发动机等组件，应该功能明确、“独立、灵活（高内聚），而且各个组件通过轻松组合（松耦合）就能得到一辆完整的汽车（相当于完整的系统）。

3.不要让易变的新业务影响现有业务的稳定性

新业务发生变化的可能性大，失败的可能性也大，因此可以考虑新建独立的微小型应用系统来支持新业务，以避免改造成熟核心系统，影响其稳定性和健壮性。

4.系统之间要实现数据的单向流转

系统之间应尽量保证数据单向流转，确保数据流可回溯，这样才能保证数据的一致性和可追溯性。混乱的数据流转会造成应用架构管理和企业经营管理的灾难。

5.综合考虑架构的合理性和业务发展的需要

应用架构设计的首要目标是支持业务发展。在企业创业初期和成长时期，业务还在试错，活下去是关键，系统建设要全力支持业务，而不要过于追求架构的完美，这一点我们已经强调多次。如果一上来就谈论整体架构的的合理性，很可能花费巨大成本实现了合理架构后，业务已经取消或失败。“优秀的架构师和CTO要懂得在合理架构设计和灵活多变的业务需求之间做出权衡。 一方面要保证整体应用的大框架是合理的，因为如果大框架有偏差，修正的代价会非常高；另一方面，在必要时要允许局部偏差的存在，局部偏差的修正成本是比较低的。对于某条产品线的负责人和产品经理来说，也要在架构的合理性和整体的业务需求之间做出权衡。

6.深入思考新系统与旧系统的关系

前面讲M集团分销平台和架构演进的时候，我们看到系统中的某些模块复用了之前的系统模块，有的则是新建的。在实际中，新旧系统的关系是架构师或条线负责人经常需要思考的：是做一套新系统还是修改旧系统？新系统如何定位？旧系统如何调整定位？数据如何流转？系统之间如何关联？底层数据如何打通？是否要复用其他系统模块？是否要将某些模块抽象化、服务化、平台化？

产品经理则要则要在自己负责的版块思考类似的问题，识别潜在的系统架构风险，必要时升级汇报问题，避免做出错误决策。

浅谈企业架构

业务架构（Business Architecture）：关注组织架构、领域模型、业务需求、业务规则、业务流程等要素。

数据架构（Data Architecture）：关注数据集成、主数据管理、元数据管理、数据治理、数据安全性等主题。

应用架构（Application Architecture）：我们所谈的企业级应用架构，就是整个EA架构中的应用架构，关注软件系统设计与公司经营管理的关系。应用架构既可以理解成软件系统的设计模式（偏技术），也可以理解成软件系统在应用功能层面的逻辑关系和视图。

技术架构（Technology Architecture）：关注服务器、网络、中间件、操作系统等偏技术层面的要点。如果说应用架构图从业务逻辑层面呈现出了软件系统的体系结构，那么技术架构图则从实现方式上呈现了软件系统的实现结构。

EA的模型和方法论体系在传统的IT管理咨询中用得比较多，主要用于帮助企业做复杂架构的梳理。另外，技术人员尤其是技术架构师，需要对EA中的某些模型和方法论有所理解。作为B端产品经理，对EA有大概的认知即可，不需要花费太多精力去研究。