-软件架构设计过程
软件架构设计尚没有万灵的方法论支持，还是个非常新兴的行业，给出个人理解的行业软件架构设计过程，受个人水平有限，仅供参考：
1.业务分析：针对目标行业的业务战略、蓝图、业务功能及流程进行分析，提出其中部分功能可以使用信息化进行处理，通过分析可以得出信息化要解决的问题。
2.解决方案设计：根据业务战略，形成行业信息化解决方案。他是一个系统组，同时明确各系统间的支撑关系。
3.系统功能设计：明确信息化系统功能列表及功能层次（层次，例如经验决策层工，管理层功能，业务操作功能等），将功能散列在这些层次中，根据功能及应用特点形成一个或者多个子系统。可参考下图理解。
4.系统架构设计：针对某一系统明确系统IT支撑表达，层次化关系表达及功能、技术核心元素
5.技术体系设计：针对系统的接口、数据存储，技术路线、部署及实现抽象进行设计
总体过程如下图所示
-系统总体架构设计
统总体架构非常重要，但在表达上都不尽相同，下面介绍几种常用的系统架构模式，供参考：
ASSF（access-service(biz)-standard-fundation)模式：访问-服务（业务功能）-标准-基础，对系统架构各个层次均有表达，但部署应用模式需要有单独说明，如下图方式组织系统总体架构：
Location模式：适合集团级应用，对于应用逻辑表达较为清晰，如下图所示：
3management-level模式：表达从决策层-管理层-操作层各个层次使用的功能。对于系统功能表达较为清晰，对于与客户达成一致性理解有较好效果，如下图所示：
个人比较推荐ASSF模式做为主架构，同时制定Location模式与3management-level模式附加说明系统，从各个层次表达系统架构。
-系统架构中的数据分布设计
在大型系统中，数据分布设计非常重要，整理数据分布设计的6中常见策略，仅供参考：
独立Schema:当一个大系统由相关的多个小系统组成，且不同小系统具有互不相同的数据库Schema定义。独立模式可管理性高，通信开销小。
集中：一个大系统必须支持来自不同地方的访问，或者该系统由多个不同的小系统组成，而数据进行集中化，统一格式存储。可管理性、数据一致性高。
分区：分为水平分析与垂直分区，当系统为“地域分布广泛的用户”提供“相同服务”时，常常使用水平分区策略。垂直分区为字段分隔，一般较少使用。采用分区方式，可伸缩性好。
复制：在整个分布式系统中，保存多个副本、并且以某种机制保持多个数据副本之间的数据一致性。复制方式可有效提升数据可靠性。
子集：“子集”是“复制”的特殊方式，就是某节点因功能或非功能考虑而保持全体数据的一个相对固定的子集。
重组：不同数据节点因要支持的功能不同，而以不同的schema保持数据---但本质上数据时同源的。重组以“重新组织”的格式进行传递和保持。
6中策略总结可以使用如下图表示：
在应用过程中，应当灵活使用各种策略，策略应用的一般化原则如下所示：
总结：在应用过程中，根据实际应用进行分析，选择合适的数据分布策略，也可以组合使用，合适的数据分布策略将使系统的稳定性及功能满足新大大提高，可以使用如下过程确定数据分布策略：
在表格中列出6种不同的数据分布策略，如下表所示：
名称对吗好吗总分独立是/否0~分...根据系统应用特点，通过以上分析，去除不适用的策略，根据总分确定所采用的数据分布策略，在有些地方也可以使用组合策略。
-系统架构中的数据集成设计
在系统架构设计中，经常面临多个业务系统数据集成共享的问题，以下主要分享数据集成设计的相关内容。
数据物理集中：将全部数据放在一起，由一个统一的数据库服务器管理，实现数据统一访问，访问效率高、适合大数据量查询的决策分析应用其缺点是实时性较差、风险大、时间长
逻辑集中：适用于业务系统分布在多个地方，由统一的整合平台实现各物理分布数据之间的数据共享，可实时访问分布在各处的数据，实施速度快，其缺点是受网络传输影响，不适合长事物。
例如在销售行业的客户信息集成，如果是逻辑集中，那就是客户数据依然存在于各个地方，但是可以通过统一的数据整合平台进行访问。如果是物理集中，则可以通过集中的数据库进行访问。
推荐结合逻辑集中与物理集中的优势，在实施初期采用逻辑集中，快速实现统一访问与数据共享，对访问量大、实时性要求不高的数据逐步实现物理集中，从而提高访问效率，类似于BI技术中的自顶向下与自底向上想结合的数据集成策略。
下面介绍数据集成设计的三种常用模式：
数据联邦模式(DataFederation)：将分布的数据逻辑集中，应用通过访问整合平台的虚拟数据库进行数据访问，数据在不同数据库实例中，此时，数据整合平台做为数据访问通道。
数据复制模式(DataReplication)：采用数据复制模式，通过数据一致性服务
实现多个数据源的数据一致性，各数据库均保留共享数据备份。
基于接口的数据集成模式(InterfaceLevel)：系统间通过接口适配器方式共享数据，比较适合实时性较高且数据量较小应用。接口模式适合分区及独立模式的数据集成。
在实际应用中，可以根据特点，灵活选用相应的策略。
-应用集成设计
系统架构设计中，多个系统经常需要进行应用交互，这时就需要进行应用集成设计，介绍几种常用的应用集成概念：
EAI：EAI(EnterpriseApplicationIntegration)，是企业应用集成EAI是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。EAI通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，完成在企业内部的ERP、CRM、SCM、数据库、数据仓库，以及其他重要的内部系统之间无缝地共享和交换数据的需要。有了EAI，企业就可以将企业核心应用和新的Internet解决方案结合在一起。
MOM：MOM指的是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。MOM交互策略如下图所示：
SOA：面向服务的体系结构（Service-OrientedArchitecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
常用的应用集成交互策略如下图所示：
在实际应用过程中，只有最适合的策略，没有最好的策略，需要综合考虑实施的复杂度，理论上来说，总线模式是比较优良的应用交互策略，可以实现完全的平台无关性与服务重用，但是相对来说改造及维护难度较大，无意中也增加了应用集成的复杂度。因此，在选择过程中需要谨慎评估集成规模及集成策略的适用性。如果企业中只有两个系统需要进行交互，采用硬编码的方式也有可能是非常适用的策略。
-接口设计
接口设计是系统架构师的重要职责，首先明确几个概念
1.协作决定接口！
2.子系统或者实现决定接口是错误的！
给出接口设计的一般步骤如下：
出处：
今天谈下架构设计中的分层思维和分层模型以及基于分层思维下的架构构图逻辑。
架构思维概述对于架构思维本身仍然是类似系统思维，结构化思维，编程思维等诸多思维模式的一个合集。由于架构的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁，因此架构思维最核心的就是要理解到业务驱动技术，技术为最终的业务服务。要真正通过架构设计来完成业务和技术，需求和实现，软件和硬件，静态和动态，成本和收益等多方面的平衡。
在前面多篇文章已经提出，架构设计中有两个重点，一个是分解，一个是集成。
分解是最基础的，架构的重点就是要对复杂问题进行分而治之，同时保证分解后的各个部分还能够高内聚，松耦合，最终又集成为一个完整的整体。分解核心是定义问题，因此架构首先仍然需要理解清楚需求。
集成是配合分解完成的动作，最终分解完成的各个组件或子系统，通过合适的接口设计，最终还能够集成为一个完整的整体，分解仅仅是加速开发和降低问题复杂度，如果分解后的内容无法集成在一起，那么分解就没有任何意义。
分解+集成可以理解为架构最核心的思考方式和方法。
在分解完成后，一个大的系统已经拆分为了诸多的小模块，或者一个小模块实现本身又分为了多个步骤阶段。那么零散的节点必须向上汇集和归纳，形成一个完整的架构。
而这个架构的形成要给关键就是要又分层思维。架构分层是谈架构绝对绕不开的一个点，通过架构分层可以更好地全面理解业务系统或功能实现。
云平台三层架构：资源-平台-应用在规划大架构的时候，常会参考云计算的标准三层架构，即IaaS层，PaaS层，SaaS层。对于IaaS层重点是IT基础设施和虚拟化；PaaS层重点是构建平台层服务能力；而对于SaaS层则是具体的应用。
对于资源层从物理资源，再到虚拟化逻辑资源，从虚拟机到现在更加轻量的容器资源。而对于平台层原来只谈技术平台，但是当前又进一步拆分出业务平台，也可以理解成当前说得比较多的中台层。
同时在平台层和应用层之间增加了服务层，实现资源和服务的解耦。
如果涉及到物联网类应用，一般还会在底层增加网络层和感知层，比如一个智慧城市标准平台和应用的架构图类似如下：
在平台+应用构建模式下，一般在平台和应用之间还会有一个单独的服务层来实现接口服务对外的能力开放。资源+服务+应用也是我们常说的SOA分层架构模式，因此对于服务层也可以单独拆分出来作为一个小分层。
问题1：数据库和数据层
在构建一个完整的总体架构的时候，实际上没有数据层这个概念，数据层是在表达单个应用系统的分层架构实现的时候才会出现的内容。
在总架构图里面把类似结构化数据库，非结构化数据等全部列出单独一层这个也不对，这个应该是在技术架构里面体现。
还有一种是单独分出一个数据层，将大的公共基础数据列出，比如上面谈的智慧城市架构图。如果这些基础数据存在共性能力朝上提供，那么可以归纳到PaaS平台层，在PaaS平台层单独分出一个数据平台域来进行体现。
问题2：服务层和服务
在构建整体架构的时候可以单独出一个能力开放平台或服务层，但是不用体现具体有哪些业务服务能力。因为单独出业务服务能力本质已经属于应用层内容，即应用又细化拆分为了业务中台和前台应用，中间衔接的服务。
我们可以参考网上的另外一个构图，如下：
这个构图既不像云平台中的分层架构，也不像应用功能实现中的分层架构。实际可以看到如果体现单独的支撑层，支撑层已经类似现在经常说到的业务中台和能力提供。
那么整个架构应该为技术平台+中台+应用方式来进行构图。
SOA分层：组件-服务-流程对于SOA架构分层，重点要体现的就是服务，对于组件本身是属于逻辑资源层的概念，而对于服务则是资源对外暴露的能力抽象。
SOA架构分层重点就是要体现出独立的服务层，注意不是画服务总线，这里可以单独画出具体提供哪些业务服务能力，技术服务能力。在采用SOA架构进行开发的时候，整体业务系统拆分为4个组件，10类服务域，5类流程，那么在构建的时候重点就是将上述组件，服务域和流程类体现出来。
对于参考SOA架构来进行的构图，参考如下:
这里的数据层最好改为标准的组件层，更加贴近SOA架构模型。在图中的服务层已经可以看到一个个独立的API服务接口。如果服务接口数据大，一般只会划分到服务域，比如用户中心服务，采购类服务等。在这种方式下构图参考如下:
在上图中结合了云和SOA两种架构融合在一起，对于上图中的服务层实际可以理解为组件资源层和服务接口层的融合。更好的构图方式应该是拆分为标准的中台资源层-服务层-应用层。
云和SOA架构融合注意对于云分层架构重点强调的是基础设施，平台和应用三层架构。而对于SOA架构强调的是资源，服务和应用三层。而对于对于传统的应用系统的构建一般又包括了IT基础设施，技术平台，数据库，中间件和应用。再到应用系统本身的分层架构可能又是标准的三层架构模式等。
这些架构分层方法都帮助我们进一步融合分层架构模式。
架构分层有很多方法，包括基础设施层，平台层，组件层，支撑层，服务层，应用层，数据层，展现层等。多种分发导致分层模型反而出现歧义和模糊。
在这里我们从技术架构和应用架构两个层面来谈，技术架构沿用云计算的三层模型；而对于应用架构则采用eTOM模型标准的资源，服务，应用三层模型。那么两种分层架构模型的融合则是一个完整的云和SOA融合的分层架构模型。
即云计算的三层中，每一个层次本身又可以进一步拆分为资源，服务和应用三层。
拿IaaS层来说，最底层的物理资源虚拟机等是属于资源层内容，通过IaaS层资源能力提供API接口作为技术服务进行能力开放，即是服务层；最终基于资源能力，构建了一个公有云的面向公众的运营服务平台，本身又属于应用层的内容。而对于SaaS层，则底层的业务组件是资源，抽象的API接口是服务层，最终的前端业务或流程是应用功能实现。
应用架构分层回到单个应用的架构分层，谈得最多的就是常说的三层架构模式。在软件架构中，经典三层架构自顶向下由用户界面层（UserInterfaceLayer）、业务逻辑层（BusinessLogicLayer）与数据访问层（DataAccessLayer）组成。
在整个实现过程中，可能还会增加独立的Facade层，或独立的API接口服务提供层，统一的DTO数据传输对象层等，但是这些都不影响整体的三层逻辑结构。
三层架构本身也和一个业务功能实现的完整对应，在数据访问层处理数据获取和持久化操作，在业务逻辑层对业务规则进行处理，在界面展现层进行相应的前端展现和用户交互。
而谈到领域建模的时候，又引入了领域模型中的分层架构，如下：
领域驱动设计在经典三层架构的基础上做了进一步改良，在用户界面层与业务逻辑层之间引入了新的一层，即应用层（ApplicationLayer）。同时，一些层次的命名也发生了变化。将业务逻辑层更名为领域层自然是题中应有之义，而将数据访问层更名为基础设施层（InfrastructureLayer），则突破了之前数据库管理系统的限制，扩大了这个负责封装技术复杂度的基础层次的内涵。
当然，也有融合了领域模型和传统三架构思路后的技术架构如下：
领域层和业务逻辑层
在领域建模的一个核心是领域模型，领域模型不再是一个个独立的数据库表或数据对象，而是一个业务对象或领域对象。因此领域层是面向领域对象而设计实现，而业务规则能力本身也是属于领域对象对外提供的能力接口。即业务规则本身也是领域对象暴露的能力。
传统业务逻辑层实现往往是一个数据对象对应一个DAO，一个Service和一个Interface。而领域模型下DAO可以是分开的，但是Service逻辑层往往则更多应该按领域模型思路对DAO层的能力进行组装和聚合。
独立应用层拆分
在我原来理解里面，领域层提供领域模型和领域服务能力接口，而应用层更多的是对领域层多个领域对象模型提供的服务能力进一步进行组装和编排，然后再暴露给前端应用。
谈到应用层的概念，实际上可以理解为前端应用中存在的共性能力的进一步下沉。即应用本身只是用户业务功能实现的承载，但是这个功能的实现可以通过多种前端展现形式，比如传统的CS桌面应用，BS应用，或手机端APP。
在电商里面，一个商品订购就是一个独立的应用，用户可以在APP完成，也可以在BS端完成，但是不论在哪里完成最终应用层提供的能力都应该一样。比如完成一个商品订购需要同时和底层的订单，库存，支付多个服务进行交付和协同。那么这个逻辑显然不适合同时在BS端应用和APP端应用中进行重复编写和开发。那么这个内容就应该在应用层实现。
如果回到微服务和中台架构下，这个应用层拆分更加必要，即通过应用层来下沉共性的服务组合和组装逻辑，这个逻辑和协同不应该属于任何一个前端应用。
界面层还是接口层
在开发一个聚合能力的中台微服务模块的时候，可以看到这个微服务模块本身并没有界面展现层，那么该微服务的最上层仅仅是提供API接口的接口服务层。
该API接口服务能力既可以提供给APP前端，也可以提供给BS端使用。
软件技术架构分层软件技术架构构图，分层仍然可以沿用软件三层分层模型，重点是说明清楚各层用到的关键技术组件或技术服务能力。比如软件开发三层模型的技术架构分层如下：
如果本身就是一个技术平台，类似大数据平台，那么我们在整体构图的时候仍然需要考虑先进行分层，再详细说明每层里面的技术内容。
比如对应一个大数据平台，包括了大数据采集，大数据存储，大数据处理，大数据分析和应用，那么这个就是关键的分层，可以基于这个分层再来考虑各层采用的关键技术。
对于技术栈构图基本也可以参考技术架构构图模式进行。
技术架构重点需要回答的就是你在进行软件架构设计过程中，究竟会用到哪些关键技术，哪些开源产品或工具等。可以细化到具体的技术产品，也可以仅细化到产品类型。
比如消息中间件，你可以细化到采用RabbitMQ，也可以在技术架构中只体现采用消息中间件。
技术架构和软件功能分层架构唯一相同的就是分层，技术架构在各个分层里面都没有具体的业务功能点和实现内容，仅仅是关键技术点说明。
单个应用功能架构注意应用功能架构完全是重点描述应用系统具备哪些功能，一个功能究竟是采用什么三层技术架构实现并不用关心。因此功能架构不应该体现数据层，逻辑层，技术点这些内容。
那么对于一个应用系统的功能如何分层？
我们可以参考业务分层分类，将业务分为基础支撑层，执行层，决策管理层。这样基本的分层模式就出来了，基于该方式可以完成一个功能架构构图。
对于单个应用来说一般不会自身有云平台，PaaS平台这类概念。但是单个应用构建一定存在共性技术支撑平台能力，比如有自己的流程管理，各自共性技术功能组件等。因此单应用构建还可以采用基础技术支撑层+应用层+门户层的方式进行构图。
在应用层再按具体的业务域或业务阶段进行进一步细分。
架构图的分层构图逻辑在前面基本给出了不同类型的架构图的核心分层逻辑，可以看到在画架构图的时候尽量不要混合使用不同场景下的构图方式，否则就导致整体架构图混乱。
在画整体架构的时候一般需要重点参考云三层架构，SOA三层架构的构图模式进行构图。而在细化到某一个应用系统的时候，仍然还需要分清是构建技术架构图还是功能架构图，两者本身的分层逻辑也存在很大的差别而不能混用。
架构图的构图逻辑
要完成一个完整的架构图构图，可以先拆分为两边+中间。两边一般是放具体的标准，规范等，比如安全管理，质量管理，技术标准规范，开发运维规范等。
中间即是重点需要考虑进行分层构建的地方。
在前面也谈到了中间部分重点参考云计算和SOA的架构分层逻辑。一般来说核心的还是资源层，平台层，应用层，门户层。而对于应用层本身又可以考虑业务域进一步拆分，或者根据价值链或业务生命周期拆分为多个阶段域再展开描述。
在云和SOA下，更加强调平台+应用构建模式。
而两者之间一般是服务层，通过SOA平台或API能力开放平台来统一接入和发布服务，以形成一个完整的资源+服务+应用的松耦合架构。
同时一个完整的架构本身就是多视角的，如下：
功能架构往往可以给具体用户和业务人员看，而对于技术架构往往更多是内部团队开发人员研讨使用。而设计到资源和平台的架构图往往又是运维工程人员进行部署架构搭建的重要参考。因此不同维度的架构分层属性本身不能随意融合使用，而导致架构图混乱。
来源：