架构设计

企业商务模型：

        企业商务模型的内容主要包括主营业务、商务模式、商务主体、竞品分析、组织架构、商务运作模型和业务流程等。1）主营业务即公司做什么业务？2）商业模式即公司怎么赚钱？3）商务主体即哪几个人在一起做这门生意？4）竞品分析即了解竞争对手的情况？组织架构即公司部门是怎么划分的，组织架构图中标出人数，根据系统与业务之间对应关系，可以了解系统中哪些模块使用频率高，以及业务与其对应模块的复杂度？5）商务运作模型即公司是如何运作的，售前做计划，找供应商把东西买进来后，经过服务和结算，再卖给我们的经销商和采购商，使我们获得利润，售后进行大数据分析最后又指导着我们的售前，整个过程形成良性循环。可以把一家公司想象成一台机器，输进去的是钱，转一转后，又能够生出更多的钱出来。6）最后是业务流程和附档资料，业务流程包括预订流程、订单处理流程、产品供应流程、财务结算流程、账户管理流程。企业商务模型的建立，指导着整个应用系统模型的建立，它是整个应用系统建设的基础和前提，毕竟应用系统是为业务服务的。

架构设计：

        架构现状的内容主要包括：功能架构、应用架构、数据设计和物理架构。功能架构主要包括功能、角色和权限三部分。

        功能是企业服务，用户使用的每一个功能，就是企业的每一个服务。角色是用户操作的归类，功能与角色的对应关系即权限。了解系统架构的现状，从功能架构开始。

        应用就是处理器，应用架构的内容包括现有架构图、Web 应用现状、作业小应用（Job）现状和接口架构。其中，接口是应用层面的关键，它是一个程序与另外一个程序交互的部分。应用架构图表列出了哪些业务逻辑没有被重用，换句话说业务逻辑被多少个应用调用，就需要被重复开发多少次，一旦改了一个地方，就要同时改多个地方，导致系统开发效率非常低下。各业务逻辑如预订逻辑，虽然被多个应用调用，但它们与应用是没有关系的，业务逻辑可以独立的存在，也可以寄宿于多个应用。业务逻辑是一个业务操作的抽象，而业务应用与业务部门共同完成了业务操作。

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

        数据的流转状态即状态图。通过数据状态图去了解现有数据流转变迁，如国内订单状态变迁图，这种图的价值不仅在于数据库层，还在于服务化。

        物理架构的内容主要包括 IDC 机房、机房之间访问关系、机房内服务器物理部署图、机房与业务分布、网站架构、数据库架构、集群清单和域名清单。将这些内容以列表和图形方式整理出来，就会很容易了解和发现问题，只有发现问题才能解决问题，特别是在全局体系架构方面，这也是表和图的价值所在。物理架构的不合理，应用架构是很难合理的，因为物理架构是我们的基础设施，位于最底层，下层为上层服务，运维要为应用服务，应用要为业务服务，业务要为客人服务。

领域模型：

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

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

架构规划：

        当我们了解了业务、了解了架构的现状，发现现有架构的问题，接下来就可以做中远期架构规划，以及架构的调整和具体实施。架构规划内容包括：顶层架构规划、网站功能规划、应用规划、SOA 规划、分层架构规划、数据库规划和物理规划等。

        在做网站功能规划的时候，更多需要考虑现状，而不是未来调整的部分，如果没有很大问题，则不做调整，尊重历史。因为有些东西（如名称）用户已经使用很久了，调整往往比较难，合理大于准确。SOA 规划就是接口规划，它的归类与商务模型中的业务流程有参考对应关系。

        先简单介绍下当前两种比较流行的分层架构体系，一种是领域架构：仓储层（Repository Layer）、领域层（Domain Layer）、应用服务层（Application Layer）、表现层（Presentation Layer）和基础公共层（Infrastructure Layer），见下图。

另一种是相对传统地分为三层：数据层（Data Layer）、应用逻辑层（Business Layer）和表现层（Presentation Layer），见下图。

        领域架构和三层架构之间有什么区别？我们是这样认为的，在早期我们做三层架构的时候，大都以表来做驱动的，在做领域架构的时候，大都以业务逻辑来驱动的，两者的区别确实比较明显。但到了现在，如果都以业务逻辑为中心的话，实际上两者并没有本质区别。当时，我所在公司采用了第二种分层法，我们希望把分层做得极简，也就是说哪怕刚毕业进来的员工，在分层时基本上也不会乱。而相对第一种分层法，第二种分层法简单很多。每一个应用的代码量都不应该很大，一旦工程变得过大，我们就会把它适当拆分，而不是全部放在一个单块应用里。总之，我认为分层越简单，整个软件结构就越清晰，代码就越容易统一。把工程做得极简，才有利于复制，有利于业务的快速构建，有利于规模化、稳定可靠。

         以上简单地介绍了总体架构的编写方法，我们的编写思路是先了解业务，建立企业商务模型，主要包括静态的商务主体、组织架构和动态的商务运作模型和业务流程。接着了解架构现状，建立现有信息系统模型，主要包括功能架构、应用架构、数据设计和物理架构。一个是商务，一个是电子，两者即是整个公司的电子商务系统。然后在企业商务模型和现有系统模型之上建立领域模型，领域模型它相对稳定，直接指导着接下来的架构规划，最后一定要落地即架构实施。

案例参考：https://github.com/das2017/TopArchDemo