应用架构之道：分离业务逻辑和技术细节.docxVIP

应用架构之道：分别业务规律和技术细节 关于架构这个概念很难给出一个明确的定义，也没有一个标准的定义。 硬是要给一个概述，我认为 架构就是对系统中的实体以及实体之间的关系所进行的笼统描述。 架构始于建筑，是由于人类进展（原始人自给自足住在树上，也就不需要架构），分工协作的需要，将目标系统按某个准绳进行切分，切分的准绳，是要便于不同的角色进行并行工作。 为什么需要架构？ 有系统的地方就需要架构，大到航空飞机，小到一个电商系统里面的一个功能组件都需要设计和架构。 我很宠爱《系统架构：简单系统的产品设计与开发》里面的一句话：结构良好的制造活动要优于毫无结构的制造活动 。 与之相对应的，现在很多灵敏思想提倡 no design，只需 work 就好。期盼好的架构可以在迭代中自然涌现。这个想法有点太抱负化了，在现实中，只需能 work 的代码，工程师是很少有动力去重构和优化的。 架构师的职责 作为架构师，我们最重要的价值应当是“化繁为简”。但凡让事情变得更简单，让系统变得更晦涩难懂的架构都是值得商榷的。 架构师的工作就是要努力训练本人的思维，用它去理解简单的系统，通过合理的分解和笼统，使哪些系统不再那么难懂。我们应当努力构建易懂的架构，使得在系统上工作的其他人员（例如设计者、实现者、操作员等）可以较为简约地理解这个系统。 软件架构 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的笼统组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段，这些笼统组件被细化为实际的组件，比如具体某个类或者对象。在面对对象领域中，组件之间的连接通常用接口来实现。 软件架构为 软件系统供应了一个结构、行为和属性的高级笼统 ，由构件的描述、构件的相互作用、指点构件集成的模式以及这些模式的约束组成。软件架构不只显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，供应了一些设计决策的基本原理。 软件架构的核心价值应当只围绕一个核心命题：把握简单性。他并不意味着某个特定的分层结构，某个特定的方法论（贫血、DDD 等）。 软件架构分类 在引见应用架构之前，我们先来看一下软件架构的分类。 随着互联网的进展，现在的系统要支撑数亿人同时在线购物、通信、消遣的需要，相应的软件体系结构也变得越来越简单。软件架构的含义也变得愈加宽泛，我们不能简约地用一个软件架构来指代全部的软件架构工作。依据我个人理解，我将软件架构划分为： 业务架构：由业务架构师担任，也可以称为业务领域专家、行业专家。业务架构属于顶层设计，其对业务的定义和划分会影响组织结构和技术架构。例如，阿里巴巴在没有大陆与台湾部门之前，每个业务部门的技术架构都是烟囱式的，淘宝、天猫、飞猪、1688 等各有一套体系结构。而后，成立了共享平台事业部，打通了账号、商品、订单等体系，让商业基础实施的复用成为可能。 应用架构：由应用架构师担任，他需要依据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的简单度把握在一个可以接受的水平，从而在快速的支撑业务进展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（功能、平安、稳定性等）。 分布式系统架构：分布式系统基本是稍具规模业务的必选项。它需要处理服务器负载，分布式服务的注册和发觉，消息系统，缓存系统，分布式数据库等问题，同时架构师要在 CAP（Consistency，Availability，Partition tolerance）之间进行权衡。 数据架构：对于规模大一些的公司，数据管理是一个很重要的课题。如何对数据收集、数据处理供应统一的服务和标准，是数据架构需要关注的问题。其目的就是统一数据定义规范，标准化数据表达，构成有效易维护的数据资产，搭建统一的大数据处理平台，构成数据使用闭环。 物理架构：物理架构关注软件元件是如何放到硬件上的，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。 运维架构：担任运维系统的规划、选型、部署上线，建立规范化的运维体系。 典型应用架构 分层架构 分层是一种常见的依据系统中的角色（职责拆分）和组织代码单元的常规实践。常见的分层结构如下图所示： CQRS CQS(Command Query Separation，命令查询分别)，最早来自于 Betrand Meyer（Eiffel 言语之父，OCP 提出者）提出的概念。其基本思想在于，任何一个对象的方法可以分为两大类： 命令(Command): 不前往任何结果(void)，但会转变对象的形态。查询(Query): 前往结果，但是不会转变对象的形态，对系统没有副作用。 六边形架构 六边形架构是 Alistair Co