这篇文章一个很重要的观点是，业务目标催生技术，而进一步演化产生架构。这种看法与自顶向下的设计模型是有区别的，更符合真实世界的映射。
这与极限编程的观点也很像，在业务需求的驱动下，使用一定技术着手实现，然后不断重构，迭代设计，产生架构。
这里从简单来看技术实现目标，架构是粘合剂，架构把技术组合起来解决问题，不过我觉得仅仅这里理解还太肤浅了些，我理解架构包含几个层次
-
需求分析
1.1 依照业务目标，提取业务需求。
1.2 依照业务需求划定业务范围，绘制上下文图，明确项目边界。
1.3 对核心业务流程建模
1.4 绘制用例图和用例规约，明确用户需求和行为需求。
-
领域建模
基于需求对核心概念建模，这部分应包含类图、状态图等
-
技术选型
基于业务目标，选择合适的开发框架、工具和语言等，并大致确定运行环境，比如是否要支持分布式，集群等等。
-
概要设计
对核心需求进行概要设计，得到鲁棒图、序列图等
-
分层和分模块
对系统进行分层设计，比如划分视图、服务、持久层。分模块则是把大系统划分为各个小系统，甚至是微服务，比如用户管理是一个独立的模块，数据导入也可以是一个独立的模块。细分模块的好处是可以理清各个模块的关系，整个软件的结构更清晰，更容易维护。