概念性架构就是对系统设计的最初的构想， 就是把最关键的设计要素合交互的机制确定下来，然后考虑具体技术的运用，设计出实际架构。概念架构并没有严格的定义，也不应该有过于严格的定义。
概念性架构设计对我们有很大的启发：
- 概念性架构通过主要的设计元素及他们之间的关系描述系统；
- 概念性架构符合“软件架构”的定义，从“架构＝组建＋交互”的角度而言，概念性架构包含概念性组件以及他们自家安的抽象交换机制；
概念组件往往是粗粒度的；
- 概念性组件包括一些高层次的设计选择，对未来软件系统的质量合功能都起着关键影响；
- 概念性架构重在点明关键机制；
概念性架构应该抓大局、不拘小节。虽然概念性架构都跳不出“架构＝组件＋交互”的基本定义，但他们描述架构的具体方式还是有比较大的差异：有的重视逻辑层，有的重视物理层，有的通过隐喻表明机制，有的看上去似乎就是一些设计元素的组合。不同的概念性架构图中，“连接”说代表的含义千差万别：有的是依赖方向，有的是控制方向，有的是数据流向，因此，必须根据具体情况而定。
概念性架构是不可以直接实现的。开发人员拿到概念性架构设计方案，依然无法开始具体的开发工作。从概念性架构到实际架构，要运用很多的设计技术，开发出能够为具体开发提供更多的指导合限制的实际架构。
包含以下3部分工作：
1.鲁棒性分析：鲁棒性分析是对用例的分析，分析出实现用例用到的哪些对象每个对象的职责对象间的调用关系，是业务到技术的一个转变过程。
2.引入架构模式：根据项目的现实情况分析需要用到的架构模式，大部分都用分层的架构，也有可能在某层上运用其它的架构模式比如在数据访问层ORM用元数据架构模式。把鲁棒分析的对象放到分析完的架构里。
3.质量属性分析：质量属性分析也是对架构设计影响很大的，如果架构漏掉了关键质量属性则会对架构设计带来很大的风险，通常使用“属性-场景-决策”表的形式带分析质量属性。比如业务人员在不同地方办公这种要求就是一个场景，这样就需要用B/S架构的决策来支撑这个场景。
鲁棒性分析
草图工具，介于分析和设计之间。
仅仅关注功能需求。
主要元素： 边界对象 交互 V
控制对象 控制 C
实体对象 信息 M
边界对象对模拟外部环境和未来系统之间的交互进行建模，负责接收外部输入、处理内部内容的解释，并表达或传递相应的结果；
控制对象对行为进行封装，描述用例中事件流的控制行为；
实体对象对需要存储的信息进行描述，往往来自领域概念。
建模原则：
(1) 参与者只能与边界对象交谈
(2) 边界对象只能与控制体和参与者交流
(3) 实体对象也只能与控制体交谈
(4) 控制体既能与边界对象交谈，也能与控制体交谈，但不能与参与者交谈
从用例图到鲁棒图
运用架构模式——微内核
微内核架构不仅将应用相关部分与通用部分分离，而且又将通用部分进一步分离成一个最小化的基本服务内核和众多扩展服务。
微内核提供一个基本服务的最小集合。这些基本服务屏蔽了其下层复杂环境的影响、并以规范的接口提供给上层的“增值服务”使用，于是所有这些附加的增值服务都和复杂环境无关。
每个软件架构师在决定采用微内核架构之前必需慎重考虑微内核架构的缺点：
- 微内核架构最大的缺点是设计和实现的复杂性，因为微内核提供的能力必须少而精，但也必须完备，否则就不能提供想要的完整“机制”。
- 微内核架构比同类情况下的其他设计性能低，要解决此问题必须精心设计与微内核架构所依据的职责模型相匹配的性能优化策略。