概念架构是大型系统架构设计成败的关键，概念架构界定系统的高层组件以及他们之间的关系，概念性架构意在对系统进行适当分解，而不陷入细节，可以与管理人员、市场人员、用户等非技术人员交流架构，概念性架构规定了每个组件的非正式规约及架构图。
如今，很多人误将“概念架构”等同于“理想架构”，对架构重要的用例驱动了架构设计，对于大多数系统，选择20%到30%的用例，然后设计、实现某个特定用例的一两个场景，就能降低大部分技术风险，并驱动架构的实现，为了实现某个特定用例，要识别出那些支持用例的软件元素，也有很多人误认为概念架构就只考虑功能而设计出来的理想化架构，其实，这是关于概念架构的最大误解 ，在实践中应当避免。
视图和视图之间是并列的关系，是一种并行思维关系，概念架构是一个“架构设计阶段”，必须在细化架构设计阶段之前，针对重大需求、特色需求、高风险需求形成稳定的高层架构设计成果。
概念架构设计分为3个步骤：
1.初步设计。基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计。这一步并不总是需要，但对于架构师而言，是“新系统”就必须重视这一步。
2.高层分割。对系统这个黑盒子进行高层切分，例如切分复杂系统为多个二级系统，或者直接切分系统为具体子系统。
3.考虑非功能需求。概念架构≠理想化架构，所以不仅要考虑功能，也必须考虑非功能。具体方法是采用ADMEMS推荐目标-场景-决策表。
鲁棒图包含3种元素，它们分别是边界对象、控制对象、实体对象。边界对象对模拟外部环境和未来系统之间的交互进行建模。边界对象负责接收外部输入，处理内部内容的解释，并表达或传递相应的结果。控制对象对行为进行封装，描述用例中事件流的控制行为。实体对象对信息进行描述，它往往来自领域概念和领城模型中的对象有良好的对应关系。
设计鲁棒图需要遵守建模规则，参与者只能与边界对象交谈，边界对象只能与控制对象和参与者交谈，实体对象也只能与控制对象交谈，控制对象既能与边界对象交谈，也能与控制对象交谈，但不能与参与者交谈。简化鲁棒图语法将有利于集中精力进行初步设计，而不是关注细节。每个场景的实现都是一连串的职责进行协作的结果，初步设计可以通过“研究用例执行的不同场景，发现场景背后应该有那些不同的职责”来完成。只对关键功能画鲁棒图，针对关键功能的鲁棒图的控制对象不必太多太细，5个是上限值。初步设计不用关注细节，不用过分关注UI。鲁棒图是设计，系统被切分成不同的职责单元，而用例规约是需求，两者有本质的区别。
高层分割的两种实践套路：切系统为系统，切系统为子系统。切系统为系统是指系统比较复杂，须进行两级高层分割，把系统切成更小一级的系统，每个更小一级的系统都可以有单独的需求、设计和实现，针对每个更小一级的系统进行切系统为子系统。
高层分割可以分为逻辑层、物理层和通用性分层技术堆叠，逻辑层重视职责的划分，职责之间常常是上层使用下层的关系。物理层指能分布在不同的机器上的软件单元，不同物理层之间必须有跨机器访问的能力，可以通过远程调用或通信协议等方式。按通用性分层是指将通用性不同的部分划分为不同的层，以此作为系统的总体切分方式。通用程度越大，所处的层次就越靠下。一般按照通用性分为4层，应用特定层、业务相关层、中间件层和系统软件层。技术堆叠不是独立的架构模式，而是基于分层架构提供的进一步说明。
重大需求塑造概念架构，重大需求应涵盖功能需求、质量约束3类需求的关键部分，概念架构是一个“架构设计阶段”必须在细化架构设计阶段之前，针对重大需求、特色需求、高风险需求，形成稳定的高层架构设计成果。目标-场景-决策表可以让架构师理性的应对非功能性需求，非功能需求会引起“架构中间设计成果”的调整。
之前我们也学过关于概念架构设计方面的知识，绘制鲁棒图十分关键，对于一个新的系统，我们需要特别重视鲁棒图的设计，在今后也要多加练习，学会鲁棒图的设计，将他与用例图区分清楚。