深入理解企业总体架构，看这篇就够了

应用架构

====

应用就是处理器，应用架构的内容包括现有架构图、Web应用现状、作业小应用(Job)现状和接口架构。其中，接口是应用层面的关键，它是一个程序与另外一个程序交互的部分。

业务逻辑被多少个应用调用，就需要被重复开发多少次，一旦改了一个地方，就要同时改多个地方，导致系统开发效率非常低下。各业务逻辑如预订逻辑，虽然被多个应用调用，但它与应用是没有关系的，业务逻辑可以独立存在，也可以寄宿于多个应用。业务逻辑是一个业务操作的抽象，而业务应用与业务部门]共同完成了业务操作。

数据设计

====

100多个数据库，一万多张表，能否使用一张E-R图来表示呢？可以的。数据设计依赖于企业的数据，而不是数据库的设计，将企业数据适当归类，会直接导致数据设计，最终画出E-R图，数据设计完成后，数据库设计就自然而然出来了。超越库、超越表去看这张E-R图，可以看出它包括产品、订单、结算、用户、基础设施这五类数据。低层的E-R图可以变，但是高层的E_R图一般不会变化，因为它是根据业务模型而定的，业务模型稳定，高层E-R图也是稳定的。数据库只要早期设计得好，是可以做到易伸缩、易拆分的。下图从内往外看，一个框既可以是一个库， 也可以是一个模块，还可以是一个表。在业务发展的早期它可以是一个库，里面有5个模块，中期可以分为5个库，后期以更低级别可以分为更多的库，这与业务阶段及系统复杂度相关。在数据的设计完成后，数据库的设计也就很容易进行规划和调整。

以上是数据库、数据表之间的静态关系，接下来我们介绍数据的流转状态，即状态图。通过数据状态图去了解现有数据的流转变迁，从等待支付到支付成功，中间有一个支付行为，通过这个支付行为把数据状态变更为支付成功，否则继续等待，直到超时关闭订单。这个支付行为可以做成一个微服务，然后由不同的应用去调用。

物理架构

====

物理架构的内容主要包括IDC机房、机房之间的访问关系、机房内服务器物理部署图、机房与业务分布、网站架构、数据库架构、集群清单和域名清单。将这些内容以列表和图形方式整理出来，就很容易了解和发现问题，只有发现问题才能解决问题，特别是在全局体系架构方面，这也是表和图的价值所在。当时这家公司共有5个地区、8个机房，虽然只有200 多台服务器，但分布很散，导致物理结构复杂，通信也很复杂。技改前故障不断，主要的原因就是物理架构不合理，运维要占60% ~ 70%的责任，当时却把责任归咎为应用架构，这是错误的方向。物理架构不合理，应用架构是很难合理的，因为物理架构是我们的基础设施，位于底层，下层为上层服务，运维要为应用服务，应用要为业务服务，业务要为客户服务。

领域模型

====

领域模型关注概念、关注职责、关注边界、关注交互，只有先确定职责和边界，交互才会很清晰。领域模型是针对现有问题域提出一个系统解决方案，然后在图表上建立完整的模型，如同用AutoCAD画的施工图纸一样。领域模型属于概要设计阶段，对于单个应用架构设计，首先需要了解业务和功能需求、用例图、用例活动图，然后才是领域模型。业务流程图是对业务操作的抽象，领域图是对业务逻辑代码的抽象。

预订模型如下图所示。

建立领域词汇是建立领域模型的第一步，它能统一词汇、 明确概念，以减少一词多义、一义多词的情况。概念一旦确定，再扩展属性和行为，然后把它当作一个单元与其他事物构建在一起，就很容易形成模型，领域模型与企业商务模型中的业务流程图有对应关系。领域模型在实现时可大可小，在业务的早期，系统比较小的情况下，它有可能是一个类。当系统做大了以后，它可能是一个DLL库。再做得更大一点的时候，它可能是一个服务，给不同的应用去调用。每一个方法都有成为服务的潜质，特别是在系统的中后期。领域模型是业务逻辑代码的施工图纸，它不仅有利于我们对现有系统业务逻辑的了解，也指导未来的架构改造。

顶层架构规划

======

以下是顶层架构的俯视图和剖面图。第一张图是俯视图，整个顶层架构最外层的是功能，中间的是业务操作，内层的是数据。功能对应业务系统的用户界面，操作对应业务系统的服务，数据对应业务系统的数据存储，如数据库。第二张图是剖面图，切一刀来看，上层是应用，中层是服务和框架，下层是基础设施数据中心。从图中的服务层可以看出，服务的归类跟业务流程的归类有很大关系。

网站功能规划

======

网站功能规划就是对功能的重新划分，对照架构现状，未来的功能应该如何调整？例如，案例中的国内网站功能规划，分别画出了全局功能图、采购商功能图、平台商功能图和供应商功能图。其实在做网站功能规划的时候，更多需要考虑现状，而不是未来调整的部分，如果没有很大问题，则不做调整，尊重历史。因为有些东西(如名称)用户已经使用很久了，调整往往比较难，合理大于准确。

应用规划

====

系统是什么？系统：元素+关系。应用架构是什么？应用架构=应用+架构。应用就是系统的最小单元，应用分类和应用编号构成了应用关系即应用的架构。如下图中的案例，应用分类新建框架Fx和公共业务系统CBS ，原有的200多个应用中并没有这两个产品线，而是分布在了不同的业务线中，从而导致重复建设。应用编号是给每个应用分配一个六位的数字ID,如同我们的身份证一样，头两位表示产品线，中间两位表示子系统，最后两位表示应用，如100206。 应用编号是应用管理、依赖和追踪的基础，集中式日志和监控框架都使用了应用编号。

SOA规划

=====

SOA规划就是接口规划，它的归类与商务模型中的业务流程有对应关系。下图中的案例有五个服务中心：预订服务、订单处理服务、产品供应服务、财务结算服务和公共服务。每个服务只需要实现一套自己的逻辑，前台、后台、接口、作业小应用等都可以调用，服务的逻辑跟业务逻辑是一致的，修改代码的时候只需要改一个地方就可以影响所有调用这服务的前端应用。

分层架构

====