系统化服务构建-软件工程分层

本文主要探讨软件项目开发中的工程，涉及软件分层，业务分离等概念。软件工程通常是说以工程的原理，原则和方法指导软件开发，以解决软件危机。

狭义的工程概念

本文中的涉及的工程概念是一个狭义的工程。

这里对工程做一个定义：软件开发中组织源代码的方式，用于实现软件开发需求，最终交付用于软件运行。工程与语言无关，或者说每一种语言都会涉及到工程，不同的语言根据语言特性会有不同的侧重。

这篇文章起源于一张图

图1-go项目文件.png

图 1 是《极客时间》一个微课程中的一张 Go 项目工程图，印证了我这些年开发设计中对于工程创建的一些理念想法，叙述如下。

业务领域模型

首先 Model 是一个业务领域概念，对应的业务模型，而非数据库字段或者说数据库字段的映射。这一点在 PHP 中被误解的尤其明显，大家都以为模型就是数据库的表映射。

为什么在 PHP 从业者眼中 Model 就代表着数据表，说白了就是 PHP 的项目业务简单到不足以启用领域模型相关的设计，进而我们可以思考 PHP 数据结构中惯用数组而非属性也是同样的道理。

思考这几个名词，客户和用户，账户和用户，通行证和用户，分别在程序上如何定义,辅以常见的产品说明? 这几个都是典型的业务域。

分层设计

图2-解决方案结构-01.png

分层设计是老话题了，软件设计的核心就是自上而下，分而治之。

图 2 是我之前架构的一个项目，自上而下，分别是应用层 Apps，服务层 Services，仓库 Repository，公共组件 Core。

理论如此，实践中的难度在于区分的粒度和度量标准。以下是几个参考：

数据层与业务层分离

数据抽象为数据访问，直接与数据存储进行交互。业务抽象为功能模块，业务组件，直接与用户交互。

数据也就是图 1 中的 DAO，图 2 中的 Repository。业务也就是 Model。DAO 与 Model 并不存在严格的对应关系。

DAO 主要与数据库存储交互，不参与业务逻辑。对外暴露的接口数据不仅仅是数据库字段的单纯映射，业务领域应该是用 Model 表示。数据层和业务层分离的实践很简单。遵循两点：

第一代码目录分离

第二数据层获取数据时，只获取不处理逻辑，不夹杂大小比较，数据类型判断等即可，抛给上层。

说起来简单，知易行难，落实了才算数。

业务组件与基础设施层分离

我们谈到基础设施，更多的会想到云计算领域的 PAAS，本文中把这个概念狭义的控制在软件层面的项目范围内。

基础设施定义为可以被抽象的，相对稳定的，对外提供服务的功能组件，对立，稳定，不易变化。英文单词 infrastructure。

相反业务组件，图 3 的 Components，被定义为可变的，灵活的功能集合。从层次的角度考虑，业务组件高于基础设施。

图3-解决方案-业务组件-02.png

复制优于依赖

Alittle copyiing is better than a litter dependcy

有时候不一定要优先追求共享代码，应该有一部分复制冗余。公用代表着多处使用，和依赖耦合。复制虽然增加了复制的成本，却独立自由。

怎么理解这句话？

我们以 YII2 工程为例，官方推荐的 Advanced 模版中有一个公共工程 common

那我们是不是应该把项目中可以共用的数据层都放到 common 里？

图4-YII2-模块.png

如上图，passport 和 admin 两个模块，如果都涉及同一张 User 表，依据复制优于依赖的原则，没有必要公用一个 User 类，可以单独存放为两个 User 类，用命名空间做隔离。更何况因为模块不一样，即使同一个数据表对象，相关的数据操作也会不一样。

总结

本文简要讨论了软件分层相关的经验和原则，软件分层，分而治之是软件工程的核心思想，从 OSI 参考模型，到 TCP/IP 应用模型，到云计算常见的业务形态，都在践行着这一思想。关于基础设施和业务组件，之前写过一篇文章系统服务化构建-项目整体框架 可以一并阅读。

大家有什么相关的疑问和建议，欢迎留言分享。

end 2019 年 12 月