企业总体架构是什么，有什么用，怎么做，如何落地，这些东西听起来非常抽象，做起来也是非常抽象。软件工程从开始到结束一般会经历需求、分析、编码、测试、部署、维护6个阶段，每个阶段都会固定的输出物，例如刚开始的产品需求文档（PRD），后面的架构设计文档等。一个应用架构设计的形成不单单是技术上，是统筹性的输出，一般分为：功能清单，用例及活动图，领域图，接口设计，分层设计，业务代码，其他设计。在现状中，梳理出现状有以下几个点
企业商务模型设计
功能架构设计
用例及活动图设计
领域架构设计
接口模型设计
分层模型设计
企业商务模型设计
一个软件的成型过程中，设计上就需要对整个商务模型进行分析，这是最重要的一环，虽然说做技术出身不用去做商务模型的从0-1的过程，但是需要做到从1-2的过程，把整个商务模型转化起来并进行落地。企业里面所有应用系统的都是建立在企业商务模型之上，它是为整个应用系统提供方向性指导。在一个商务模型里面，基本涉及了主营业务，商务模式，运营模式，主营产品，竞品分析和业务流程等。很多公司在开始做应用软件之前，整体的商务模式基本上已经是清楚的，此时的设计阶段就趋向于需求调研阶段。
图1：某公司CRM基础商务模型
主营业务指的是工作是以什么业务为生；商务模式即公司如何赚钱；运营模式比较复杂，企业内部的人力资源管理，财务管理，技术管理，生产运营管理，市场营销管理五部分组成；主营产品比较好理解，即是公司所服务或者销售的主要产品，一般是公司里面的拳头产品；竞品分析，不知道哪位大佬说过，有人的地方就有江湖，有产品的地方就有竞品。客观上来说，竞品分析是从竞争对手或者市场上的相关产品中，针对特定的考察角度，分析出现状情况以及跟自己的产品进行对比，必须客观并且真实，做横向对比（图2及图3）；业务流程指主营业务从产生到最后出门的整个流转过程，最终目的都是盈利。
图2：医疗信息化市场规模及其预测
图3：近10年中国人口数量及人口增长率
功能架构设计
在功能设计上要做好，一般从三个方面切进去：功能设计，角色设计，资源权限设计。
2.1、功能设计
功能设计上一般以模块为类别，由大模块开始不断下放到各个小功能最终组成功能性图表，同时展示了所有功能的从属关系（图4）。
图4：春雨医生功能架构设计
2.2、角色设计
每一个系统都会进行角色设计，指的是系统里面有多少角色，一般角色在定义的时候是根据业务需要来制定。以角色定义业务，以业务定义模型。
3W原则：3W原则是最常见的做法，WHO，WHAT，HOW这三者来区分。
WHO：用于描述主要运用于哪些角色？这些角色是干嘛的？在整个3W体系中，相对于用户体验上来说，这个是最重要的存在，系统的使用者，企业的业务使用方，领导层，决策层关心所关心的往往就是自己能通过这个角色看到什么内容，通过这些内容能判断出或者从中获取对企业有帮助的信息，例如往年规划，接下来可能会发生的事情等。
WHAT：用于描述具体做什么业务，在这一层里面更趋向于具体的业务使用人员，每一个系统的使用人员需要非常清楚自己究竟是做什么？
HOW：在上面知道做什么后，接下来系统要帮助的就是怎么做的问题。从系统的产生到系统的消亡，每一个软件都是有一定的生命周期的，这个生命周期本质上来源于业务的不断变化，映射出业务也是有一定的生命周期，在这个系统里面，要告知每一个业务使用人员，业务是如何通过这个系统怎么做？
3W原则举例
2.3、资源权限设计
资源权限设计对于所有后台系统来说，是一个最重要的部分，主要是针对不同人可以访问不同的资源权限，接口权限，数据权限等，这些权限的控制上的缺少或者操作问题引发的风险，是非常巨大的，最直接的后果就是导致数据串联了从而隐私数据泄漏。
目前很多公司采用微服务进行设计开发，权限系统自然需要独立出来并实现独立的管理，整个权限设计中，从简单到复杂分为7种，RBAC0模型，RBAC1模型，RBAC2模型，RBAC3模型，用户组，组织，职位，含有组织/职位/用户组的模型。
RBAC0模型
RBAC1模型
RBAC2模型
组织
职位
含有组织/职位/用户组的模型
以上7种模型的设计主要还是集中在资源权限的设计上，也就是我们最常见的菜单级别的设计，这一块的设计对于整个系统来说是最重要也是最基础的存在，是后面我们要进行接口权限，数据权限权限的根基。接口的权限设计的颗粒度是以每个接口中作为资源的颗粒度，这个接口是与每个服务进行挂钩并由超级管理员统一分配给上面的角色或者用户，在进行数据授权的时候统一处理好并返回给用户，这一层的设计上有多种多样，如果存在网关的存在，在进行鉴权的时候一般都放在网关上并结合redis进行鉴权。数据权限比较简单，每个服务或者每个系统都有自己特定的业务权限数据范围，根据角色获取这些角色可访问的数据范围即可。
备注：接口的鉴权上，可以采用接口注册->接口分配的方式进行，接口注册可以自定义注解进行自动注册或者手动在后台的接口管理上进行手动添加，如果是自动注册的话，一般后台设计上不允许修改，避免影响接口的访问，但是提前约定好规则。
3大资源鉴权整合参考
用例及活动图设计
用例图是非常常见的图，在UML的所有图中，它应该算是最需要并且最快需要确定的图，每一个用例图跟产品功能上存在对应关系。
用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图举例
用例活动图是从用例图拓展而来，每一个用例活动图展开后即可变成用例活动图，从两个角度来分析对用例活动图的内容
产品经理：产品经理从用例活动图，获取到的是整体或者个体的业务逻辑。
研发人员：研发人员从用例活动图，获取到的是整体或者个体的程序上的业务逻辑。
业务用例工作流程说明了业务为向所服务的业务主角提供其所需的价值而必须完成的工作。业务用例由一系列活动组成，它们共同为业务主角生成某些工件。工作流程通常包括一个基本工作流程和一个或多个备选工作流程。工作流程的结构使用活动图来进行说明。
工作流程活动图用于研究实现业务目标时所要执行的各项任务或活动的顺序安排。活动既可以是手动执行的任务，也可以是自动执行的任务。它可完成一个工作单元。
活动图是状态图的一种特殊形式。其中所有或多数状态都是活动状态，而且所有或多数转移都在源状态中的活动完成时立即触发。
用例活动图举例
领域架构设计
在以往的设计中，领域架构设计往往并没有出现，从用例开始后整体就开始进入到系统的接口设计，但是微服务的出现导致领域驱动设计开始流行。
领域架构设计中我们今天不深究，今天这部分只说说领域图的设计。领域图是从用例活动图演变而来，相对于用例图，它是整个用例的细化展示。领域图是应用程序中的业务逻辑模型，它的每一个对应的方框可大可小，或是子系统、或是服务、或是类库、或是单个类，实现微服务的本质性可伸缩性、可拓展性。
领域模型在整个面向对象的设计中是最简单，也是最困难的一部分，对于一个领域模型来说，在面向对象的设计中有个重要的思想就是把事情交给最合适的类去做，这需要不断是联络各个类之间的关系，从语言层面来讲，它具备 5 方面的特性：
1、存在父类，专门用来存储所有子类的公共属性，并且这个类并不是一个值对象。
2、存在实例的字段
3、存在实例的属性
4、存在自己的领域逻辑，具像化来理解就是存在公共的与私有的方法
5、存在自己的领域服务，这个领域服务是静态方法static，并且这个方法可以单独放出来放到特定的服务类中。
领域模型图举例
接口模型设计
接口模型设计在现在的前后端分离的系统中是最重要的，直接关系到应用的便捷性。
应用的多样化需要我们在对接口进行设计的时候多考虑接口的边界问题，可以参考：《springboot2.2.X手册：构建多元化的API接口，我们这样子设计》。
每一个接口都有生命周期，如何去管理可以参考：《微服务手册：API接口9个生命节点，构建全生命周期管理》。
那回归接口本质，接口其实是一种契约精神，一种约定俗成的规则，一种应用与外部世界的连接者，一种应用与其他应用的交互者，是让整个业务能成功流转起来的源头，但是接口并不关心里面的具体实现，这些是服务层的事，但是接口有个通用性的原则，那就是一定遵循请求与输出Request/Response。
接口文档举例
分层模型设计
在第五点的接口设计中，接口并不关心服务层的具体实现，但是分层模型设计中关心的就是逻辑的具体实现。现在最常用的分层设计中，最常见的还是三层架构的设计，虽然领域横行，但是学习成本是个非常需要考虑的问题，整体在进行分层中坚持的思想是：分层越简单明了，理解起来就越简单，代码越容易统一编写，相对于整个工程来说，这样子的结构是最有利于业务的快速迭代，并让这个系统更加稳定可靠。在做整体的分层设计的时候，尽可能保持不要为了炫技而做设计，要考虑更多同学的学习力的问题。目前小编除了在接口层做领域的区分外，其他的还是坚持原来的三层设计，这样子新来的同学可以很快上手，“面向领导”编程更有优势了。
其他项
除了上面说的，还有数据库设计，物理架构设计，非功能性设计等。数据库设计一般有E-R图与表设计，数据设计规范等；物理设计有部署图，高可用或者集群部署图，域名等；非功能性设计一般主要把安全放在第一位，其余是性能、高可用、弹性伸缩、拓展性等。最后整合成一份完成的架构设计文档。
--END--
作者：@溪云阁
原创作品，抄袭必究
如需要源码，转发，关注后私信我
部分图片或代码来源网络，如侵权请联系删除，谢谢！
