https://blog.csdn.net/nnsword/article/details/62228503.
逻辑架构：关注功能。不仅包括用户可见的功能，也包括一些基础模块以及辅助模块。
开发架构：关注程序包，不仅包括要编写的程序，还包括可以直接使用的第三方SDK或者现成的框架、类库以及开发的系统将运行于其上的系统软件或者中间件。
运行架构：关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。
物理架构：关注‘目标程序及其依赖的运行库和系统软件’最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。
数据架构：关注持久化数据的存储方案，不仅包括实体及其实体关系的数据存储格式，还包括数据传递、数据复制和数据同步等策略。
运行架构和开发架构的关系：开发架构一般偏重于程序包在编译时期的静态依赖关系，而这些程序运行起来后会表现为对象、线程、进程，运行架构比较关注这些运行时单元的交互问题。
物理结构和运行架构的关系：运行架构特别关注目标程序的动态执行情况，而物理架构重视目标程序的静态位置问题；物理架构还要考虑软件系统和包括硬件在内的整个IT系统之间是如何相互影响的。
数据架构和物理架构的关系：对于很多集成系统，数据需要在不同系统之间的传递、复制和暂存，这往往要涉及到不同的物理机器。
五种架构视图的关注点各有侧重。逻辑架构侧重功能需求；开发架构侧重开发期间质量属性；运行架构侧重运行期质量属性；物理架构侧重安装和部署需求；数据架构侧重数据需求。
两个问题：
多个架构视图之间的同步问题
不同的软件架构视图之间不是独立的，它们分别从不同的角度反映了一个软件系统的特性，所以之友它们合在一起时，才是一个完整的软件系统，所以需要保持各个视图之间是相互解释的，而不是相互矛盾的。
架构视图的数量问题
忌讳为了架构而架构，不是所有类型的软件系统都需要所有的5个视图。例如对于不涉及到数据存储的系统，那么是不需要数据架构的；对于单机版的系统，不涉及到分布式的需求，那么物理架构相对来说也比较简单。
---------------------
==
软件架构设计-五视图方法论
https://blog.csdn.net/nnsword/article/details/78109126
在实际工作中，我们经常听到“架构”和“架构师”这样的名词，并不新鲜，但是总让很多刚入门的人感觉很神秘，甚至是高深莫测。很少有人对“架构”有全面的了解和认识能并说清楚架构是什么，更谈不上掌握了。事实上，也只有极少数人能成为或者被冠以“架构师”这样的title。为此，笔者总结了对架构的一些理解，希望能够补充很多初入门的人在这方面认识上的不足，纠正一些误解。高手和老鸟就直接跳过吧。
架构的分类
对于“架构”来讲，理论上划分了5种架构视图，分别是：逻辑架构、开发架构、运行架构、物理架构、数据架构。根据名字，大家都可能大概能猜到其侧重点和含义。这里先用通俗的文字简单介绍下，便于大家理解，大家可以不必纠结概念和这些理论。
逻辑架构：逻辑架构关注的是功能，包含用户直接可见的功能，还有系统中隐含的功能。或者更加通俗来描述，逻辑架构更偏向我们日常所理解的“分层”，把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。
开发架构：开发架构则更关注程序包，不仅仅是我们自己写的程序，还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台，以及主流的基于数据库的应用，都会比较关注。和逻辑架构有紧密的关联。
运行架构：顾名思义，更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题，比较常见的“线程同步”问题、死锁问题、对象创建和销毁（生命周期管理）问题等等。开发架构，更关注的是飞机起飞之前的一些准备工作，在静止状态下就能规划好做好的，而运行架构，更多考虑的是飞机起飞之后可能发生的一些问题。
物理架构：物理架构，更关注的系统、网络、服务器等基础设施。例如：如何通过服务器部署和配置网络环境，来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子，如何通过设计基础设施的架构，来保障网站能支持同时10W人在线、7*24小时提供服务，当超过10W人或者低于10W人在线时，可以很方便的调整部署架构来支撑。
数据架构：数据架构，更关注的是数据持久化和存储层面的问题，也可能会包括数据的分布、复制、同步等问题。更贴切来讲，如何选择需要的关系型数据库、流行的NOSQL，如何保障数据存储层面的性能、高可用性、灾备等等。很多时候，和物理架构是有紧密联系的，但它更关注数据存储层面的，物理架构更关注整个基础设施部署层面。
上面讲了那么多，相信国内很少有公司是严格按照这五种视图去分工和设计的。其实在笔者眼中，架构大致分为两种：软件架构、系统架构。前三种视图，可以归纳为软件架构，而后两种架构，则归为系统架构。这也比较符合国内大部分中小型互联网公司的现状。
根据应用特性的不同，关注侧重点可能不同。例如，某些门户类的互联网应用，读多写少而且业务相对比较简单，则更加关注“高性能、可伸缩性、可用性”等方面。对于更加复杂的应用，例如电商类大规模交易型的应用，对每个层面和每个环节都会比较关注。对于业务型的系统，例如一些生产型企业使用的ERP，或者仅供企业内部使用的一些MIS、OA应用，通常更关注功能和复杂的业务和实现和扩展，而对性能等方面又可能不要太高，这类应用则更关注纯软件架构层面。这里，不展开做具体讨论。所以很多时候，架构师也需要是一个团队，而不是一个人“全栈”。
架构设计到底是什么
在长期的技术招聘面试中，我发现在很多人眼中，架构就是分层，架构设计就是“三层架构”（或者四层、五层…反正分层越多就说明项目越复杂而且架构就越牛），或许是受到诸如PetShop之类的示例项目的影响，这里暂时不去追究原因了。
之前已经纠正过很多人的误解-架构不只是软件架构。说一下通俗点的理解：
软件架构就是实用而且优雅的设计，它不在于分多少层，或者应用了多少种设计模式/架构模式等。它应该是以满足实现用户需求为前提，以开发人员普遍可接受为根本的，而且要符合系统特性和业务发展需要的，从软件设计的角度，能够达到层次清晰、可维护、可重用、可扩展…就非常优秀了，无需刻意去纠结分了多少层，是否使用了什么模式，有多么抽象等。以面向对象设计为例，基本目标是“高内聚、低耦合”，为此我们可能会遵循一些常见的设计原则（例如经典的SOLID设计原则）。最后纠正一点，通常我们所说的模式，其实又分为很多种，并不是仅仅指的是“设计模式”（设计模式也有千千万，并不是只有常见的GOF 23种设计模式）。通常包括：企业架构模式、设计模式、SOA模式、企业集成模式等等。
强调一下，架构要讲求“实用”，而且开发人员普遍可接受，要符合现状的。否则，再“优雅”的设计，都会沦为高成本的“花架子”，生搬硬套和过度设计只会让项目“流产”。
由于角色和分工不同,软件架构是一个复杂的整体，软件架构工程师不可能在一个视角、一下子讲清楚，而利用多重软件架构视图的方法，可以一次只围绕少数概念和技术展开，分别着重研究软件架构的不同方面，使问题得以清晰公和简化，利于软件架构工程师完成架构设计工作。
因此软件架构的每个视图分别关注不同的方面，针对不同的目标和用途。目前常用架构设计五视图方法进行软件架构描述。它们分别是逻辑架构、开发架构、运行架构、物理架构和数据架构。
逻辑架构的设计着重考虑功能需求，系统应当向用户提供什么样的服务，关注点主要是行为或职责的划分。逻辑架构关注的功能，不仅包括用户可见的功能，还应当包括为实现用户功能而必须提供的辅助功能。逻辑架构的静态方面是抽象职责的划分，动态方面是承担不同职责的逻辑单元之间的交互与协作。
开发架构的设计着重考虑开发期质量属性，关注点是在软件开发环境中软件模块（包）的实际组织方式，具体涉及源程序文件、配置文件、源程序包、编译打包后的目标文件、直接使用的第三方SDK/框架/类库、以及开发的系统将运行于其上的系统软件或中间件。
运行架构的设计着重考虑运行期质量属性，关注点是系统的并发、同步、通信等问题，这势必涉及到进程、线程、对象等运行时概念，以及相关的并发、同步、通信等。运行架构的静态方面关注软件系统运行时的单元结构，动态方面关注运行时单元之间的交互机制。
物理架构的设计着重考虑安装和部署需求，关注点是目标程序及其依赖的运行库和系统软件最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性、持续可用性、性能和安全性等要求。
数据架构的设计着重考虑数据需求，关注点是持久化数据的存储方案，不仅包括实体及实体关系数据存储格式，还可能包括数据传递、数据复制、数据同步等策略。
在运用五视图方法进行架构设计时需要注意两个方面的问题：一是多个架构视图间的同步问题，也就是必须保证不同视图之间是互相解释而不是相互矛盾的；另一个是架构视图的数量问题，原则上是软件系统不涉及某方面的要求时就不需要该方面的视图，严格控制架构视图的数量，但如果有需要，可以引入新的架构视图，从而更加突出和明确地制定和表达特定方面的架构决策，如安全性。
构成每个架构设计视图的元素不同，这些不同的元素撑起不同的思维空间，从而使每个架构视图重点覆盖不同种类的需求，最终所有架构设计视图所表达的语义综合左右一起，就构成了软件架构设计方案。
---------------------