01 | 架构的本质：如何打造一个有序的系统？

作者回复: 专栏里说三种架构分别从概念，逻辑和物理层面定义系统，那我们如何判断一个实际的架构图，它是业务架构，还是应用架构，技术架构呢？ 业务架构关注系统大的业务流，数据流和资金流，举个例子，假设A要通知B，在业务架构里，我们简单标识A"通知"B，过程中传递了什么信息即可； 在应用架构图里，这个具体的通知方式要给出，也就是从逻辑上理解这个过程是怎么回事的，可能是A同步调用B；也可能是B定时轮询A的接口获取信息，还有可能是A先发送消息到MQ，然后有个监听应用负责接收消息，然后调用B的接口实现。 而如果是技术架构，还要把具体的MQ技术选型给出来，是RabbitMQ呢，还是Kafaka。 当然在实际的架构图里，不会都按照这个分类来描述，很可能有些地方按照业务架构简化表达，有些部分给出具体的技术选型，这个我们清楚就可以，不必太纠结，不是每个系统都要给出3个架构图，那太麻烦。

作者回复: 系统架构是一个比较含糊的概念，实践中，也经常被人提到，如果按照业务架构，应用架构，技术架构的分类，系统架构实际上更偏向于技术架构。 专栏里说三种架构分别从概念，逻辑和物理层面定义系统，那我们如何判断一个实际的架构图，它是业务架构，还是应用架构，技术架构呢？ 业务架构关注系统大的业务流，数据流和资金流，举个例子，假设A要通知B，在业务架构里，我们简单标识A"通知"B，过程中传递了什么信息即可；在应用架构图里，这个具体的通知方式要给出，也就是从逻辑上理解这个过程是怎么回事的，可能是A同步调用B；也可能是B定时轮询A的接口获取信息，还有可能是A先发送消息到MQ，然后有个监听应用负责接收消息，然后调用B的接口实现。 而如果是技术架构，还要把具体的MQ技术选型给出来，是RabbitMQ呢，还是Kafaka。 当然在技术的架构图里，并没有很明确地按照这个来给出，很可能有些地方按照业务架构简化表达，有些部分给出具体的技术选型，这个我们清楚就可以，不必太纠结，不是每个系统都要给出3个架构图，那太麻烦。

作者回复: 分解为不同抽象层次是对的，但组合时，一般我们不说树的结构，而是层次化结构，你看具体的业务架构，都是层次结构，一个层可以把多个定位相同的模块包含在一起，简化整体依赖关系，当然也不会有循环依赖的问题。 下一讲就会深入地讲业务架构。

作者回复: 架构处理的原则是相同的，类似你会了一门语音，再学新语言就非常快。你可以对照自己熟悉行业的业务系统，去理解它们的系统设计。一般来说，电商行业交易相关的系统设计具有比较好的典型性，其他行业对核心的业务模型了解下就可以。

作者回复: 哈哈，夸奖了。

作者回复: 很好的思考，特别是技术人员随着职位的提升，关注点会前移。从业务出发，系统架构设计会有针对性，接地气，避免过度设计。

作者回复: 是的，这是一种比较典型的分类。数据架构之前主要就是关系数据库，不怎么强调。现在随着大数据的发展，我们关心数据有哪些格式，数据如何分布，如何流转，数据架构也越来越重视。

作者回复: 这样理解也可以，但偏简单化。 业务架构是纯粹站在业务的角度，对业务进行分解和重新组织，不同的分解方式影响我们对业务的理解，以及后续的业务的扩展和重用能力。 应用架构是站在系统如何分解和组织的角度，它和业务和技术都有关系，有些和技术有关，比如BS还是CS，要不要网关，要不要把短信发送独立包装成服务方便调用等；当然更多地是和业务有关，比如订单服务针对订单业务，商品服务针对商品业务，当然业务模块和应用也不是1对1的关系，通常来说，业务模块的粒度比应用要大一点，但也有时候，一个应用包含多个业务的内容，比如一个管理后台的应用，就包含多个业务的后台。 架构师通过业务架构和产品经理和业务方沟通，对于开发来说，当然是应用架构更具体一些。 业务架构和应用架构是从不同角度看系统，虽然应用架构受业务架构的影响很大，但不能简单认为应用架构是业务架构的细化，它也有相对独立的一面。

作者回复: 业务架构师和技术架构师都是一种角色，或者说职责。没有条件的话，企业没有架构师，开发兼；有条件的话，有架构师同时兼这两个角色；条件很好的话，不同的人担任这个角色

作者回复: 应用架构不能归到业务架构，它承业务架构，启技术架构，对开发来说，他和应用架构关系最密切。有些应用架构和业务没有关系，比如网关，它也是一个应用，用于连接前端和后端，但它处理系统级功能有关，和业务功能无关。 如果说对于开发来说，最重要的是逻辑能力，那对于架构师来说最重要的是抽象思维能力，然后是学习能力（技术和业务）和平衡取舍能力。