读 《理清技术、业务和架构的关系》有感

今天读了架构漫谈九：理清技术、业务和架构的关系 有些感触，结合自己的一些经验谈下自己的想法。

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

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

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

1. 需求分析

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

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

    1.3  对核心业务流程建模

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

2. 领域建模

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

3. 技术选型

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

4. 概要设计

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

5. 分层和分模块

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

架构要考虑的东西还是很多的，不过我比较认同敏捷的观点，先基于核心业务按上面的过程大致架构，不必太细，然后不断迭代和重构。