本文主要探讨软件项目开发中的工程，涉及软件分层，业务分离等概念。软件工程通常是说以工程的原理，原则和方法指导软件开发，以解决软件危机。
狭义的工程概念
本文中的涉及的工程概念是一个狭义的工程。
这里对工程做一个定义：软件开发中组织源代码的方式，用于实现软件开发需求，最终交付用于软件运行。工程与语言无关，或者说每一种语言都会涉及到工程，不同的语言根据语言特性会有不同的侧重。
这篇文章起源于一张图
图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 月
网友评论