前面说到了“准备做”的内容，本节将讲述如何“做”！人们更愿意叫它“概念架构”，因为人们都比较喜欢文艺！
程序猿出生的人，都比较喜欢用专业的词汇来理解架构，尤其喜欢高深莫测的技术。所以，开发者更喜欢“架构 = 模块 + 接口”这一说法，主要还是因为它贴近程序猿的身份，一提到接口，大家都乐了，有了接口就可以去实现接口，有了接口就知道模块间的联系，仿佛大千世界就只有用接口才能沟通你我，才能联系彼此！
当然，对于架构来说，接口是非常重要，但只针对于程序猿！对一个架构师来说，更重要的是统筹全局，把握大的框架，而不用太关注细节，接口嘛，可以由精明的程序猿来定。
概念架构的核心是：架构 = 组件 + 交互
组件：只需要关注高层组件；交互：高层组件间的关系，不应涉及接口的细节。
概念架构的流程
概念架构可以分三个阶段来完成。
1.初步设计
该阶段可以基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计，这一步并不总是需要，但是对于一个新项目来说，一定要重视此步骤。
关于鲁棒图的介绍，可以参考本人的论文：鲁棒图
2.高层分割
高层分割实际上是对整个系统这个庞大的概念进行切分，可以切分为多个二级系统，或者直接切分为具体子系统。分层的手段有多种，可以按照逻辑来分Layer，也可以按照物理来分Tier，还可以按照通用性来分，总之，它不是固定的，你可 以选择一种方式，也可以多种方式并存。
下文将分章节介绍逻辑层、物理层、通用性分层。
在高层分割的大思路下，还得考虑一下技术性问题。可以把每一层需要用到的技术描述出来。下图给一个示例：
该图就结合了通用性分层和技术堆叠，当然，这只是一个简要的例子，实际过程中可能会用到更多的技术和更复杂的框架。但是对于架构师来说，他可以把自己团队具备的技术都给利用上。
3.非功能需求
非功能需求，只要记住一个词：质量！非功能需求往往是非常的笼统的，在第一阶段的时候，也强调过。总之，在概念架构阶段需要考虑到非功能需求的限制。其实，“质量”是贯穿整个架构阶段都要考虑的，而且要趁早，越早考虑越好。产品
都做完了再去考虑非功能性需求是悲哀的。
本节讲述了概念架构的流程，流程里面有些需要深究的地方，如鲁棒图、逻辑层等需要在接下来的章节中详细探究。