阅读笔记-理清技术、业务和架构的关系

这篇文章一个很重要的观点是，业务目标催生技术，而进一步演化产生架构。这种看法与自顶向下的设计模型是有区别的，更符合真实世界的映射。

这与极限编程的观点也很像，在业务需求的驱动下，使用一定技术着手实现，然后不断重构，迭代设计，产生架构。

这里从简单来看技术实现目标，架构是粘合剂，架构把技术组合起来解决问题，不过我觉得仅仅这里理解还太肤浅了些，我理解架构包含几个层次

1. 需求分析

   1.1 依照业务目标，提取业务需求。

   1.2 依照业务需求划定业务范围，绘制上下文图，明确项目边界。

   1.3 对核心业务流程建模

   1.4 绘制用例图和用例规约，明确用户需求和行为需求。

2. 领域建模

   基于需求对核心概念建模，这部分应包含类图、状态图等

3. 技术选型

   基于业务目标，选择合适的开发框架、工具和语言等，并大致确定运行环境，比如是否要支持分布式，集群等等。

4. 概要设计

   对核心需求进行概要设计，得到鲁棒图、序列图等

5. 分层和分模块

   对系统进行分层设计，比如划分视图、服务、持久层。分模块则是把大系统划分为各个小系统，甚至是微服务，比如用户管理是一个独立的模块，数据导入也可以是一个独立的模块。细分模块的好处是可以理清各个模块的关系，整个软件的结构更清晰，更容易维护。