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