再说细化架构之前，先说说：“架构师到底该干什么”，是不是架构师提交完《架构设计文档》之后，就彻底没有事了呢？
如若这样，那么就苦了程序员了，只有概要架构，没有细化架构对于程序员来说无异于加大了程序员的工作。为何会如此，我们先来了解一下细化架构和概要架构就很方便理解了。
-
- 接口，对于概要架构来讲，无需涉及到接口层面，只需要分析到每个模块的功能或者是职责就可以了。相反在细化架构中也就是程序员编写程序的途中，接口的定义就显得很重要了。
- 子系统，在细化架构中，子系统便于我们分割系统功能，降低程序的耦合度，是代码更加容易理解并且子系统往往具有明确的接口；而在概要架构中，尽管有抽象都组件来分割功能，但是这就相当于一个公司的整个工作车间，而没有对整个工作车间进行下一步划分，比如说：一个生产车辆的车间，概要设计是划分了车的发动机、底盘等车间，而没有对发动机车间进行再一次的细化。概要设计中也有“大组件分解位小组件”的含义，但是并不符合子系统的含义。
- 交互机制，再细化架构中交互机制是“实实在在”的，比如：接口的调用、参数的传递、函数调用等等，这种交互机制的定义可以方便程序员快速理清程序的脉络，能更快的设计出合格的程序。而概念架构中的交互机制是概念化的，只是定义了这两个层之间有关联关系：“A层使用了B层的服务”。
这里有一则故事《什么是软件架构》，在深入理解下细化架构：
我第一次看这则故事的时候，也在想这么一个问题软件架构到底是什么，它到底包括哪几方面呢？
故事中每个职业对架构的理解都不一样，那么到底那个是对的呢，还是他们说的都对？答案很显然，一个好的软件架构师应该能将这些情况都考虑在内，那么这么多情况呢谁能保证自己不忘了一个或者少考虑了一方面。这时候就需要对架构进行进一步的细化分类。
将架构细化，运用多视图的方法对架构的层面进行划分，这样能理清架构思路，也能统筹大局，把握好系统架构。
参考文献：
温昱，《一线架构师实践指南》