区块链、WF、SAAS、EIP、ERP、HIS、B2B、B2C、CRM、OA等行业咨询及解决方案
概念架构是一个架构设计阶段，必须在细化架构设计阶段之前，针对重大需求，特色需求、高风险需求、形成文档的高层架构设计成果。
重大需求塑造概念架构，这里的重大需求涵盖功能、质量、约束等3类需求的关键内容。
如果只考虑功能需求来设计概念架构，将导致概念架构沦为“理想化的架构”，这个脆弱的架构不久就会面临“大改”的压力，甚至直接导致项目失败。
二、概要架构阶段的方法及科学实践过程是什么？
整体可分为3个阶段：
1、通过鲁棒图：初步设计的目标就是发现职责，运用“职责协作链”原理画鲁棒图
2、高层分割：运用成熟的经验及方法论，结合场景选择合适的架构模式来确定系统的层级关系
3、质疑驱动：考虑非功能性需求来不断驱动概要架构设计过程。
2.1、初步设计的目标就是发现职责，运用“职责协作链”原理画鲁棒图
鲁棒图的三种对象：
•边界对象对模拟外部环境和未来系统之间的交互进行建模。边界对象负责接 收外部输入、处理内部内容的解释、并表达或传递相应的结果。
•控制对象对行为进行封装，描述用例中事件流的控制行为。
•实体对象对信息进行描述，它往往来自领域概念，和领域模型中的对象有良好的对应关系。
初步设计原则
•初步设计的目标是“发现职责”，为高层切分奠定基础
•初步设计“不是”必须的，但当“待设计系统”对架构师而言并无太多直接 经验时，则强烈建议进行初步设计
•基于关键功能（而不是对所有功能）、借助鲁棒图（而不是序列图，序列图太细节）进行初 步设计
关于这几个对象的区别，请参考《
通过上面的对比我们发现，鲁棒图能够更全面的体现架构设计过程中涉及的内容，单独的架构模式更侧重其中的部分架构层次，比如逻辑架构采取MVC的模式。
2.2、高层分割（概念架构形成的具体操作方法）
1）、直接分层
2）、先划分为子系统，再针对每个子系统分层
针对高层分割，我们可以采取分阶段的模式来进行落地实践：
1、直接划分层次：直接把系统划分为多个层次，梳理清晰各层次间的关联关系
2、分为2个阶段：先划分为多个子系统，然后再梳理子系统的层次，梳理清晰没格子系统的层次关系
针对分层模式的引入，这里分享几类划分模式及方法：
1、逻辑层：逻辑层，上层使用下层观念；不关注物理划分，也不关注通用性
2、物理层：分布部署在不同机器上
3、通用性分层：通用性越多，所处层次越靠下
2.2.1、Layer：逻辑层
Layer：逻辑层，上层使用下层观念；不关注物理划分，也不关注通用性。Layer是逻辑上组织代码的形式。比如逻辑分层中表现层，服务层，业务层，领域层，他们是软件功能来划分的。并不指代部署在那台具体的服务器上或者，物理位置。
多层Layer架构模式
诸如我们常见的三层架构模式，三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。
逻辑层次的架构能帮助我们解决逻辑耦合，达到灵活配置，迁移。 一个良好的逻辑分层可以带来：
A、逻辑组织代码/代码逻辑的清晰度
B、易于维护（可维护性）
C、代码更好的重用（可重用性）
D、更好的团队开发体验（开发过程支持）
2.2.2、Tier：物理层
Tier：物理层，各分层分布部署在不同机器上，Tier这指代码运行部署的具体位置，是一个物理层次上的划为，Tier就是指逻辑层Layer具体的运行位置。所以逻辑层可以部署或者迁移在不同物理层，一个物理层可以部署运行多个逻辑层。
