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

发布于: 12 小时前
系统化服务构建-软件工程分层

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

狭义的工程概念

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

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

这篇文章起源于一张图

Go 项目结构

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

业务领域模型

首先 Model 是一个业务领域概念,对应的业务模型,而非数据库字段或者说数据库字段的映射。这一点在 PHP 中被误解的尤其明显,大家都以为模型就是数据库的表映射。为什么在 PHP 从业者眼中 Model 就代表着数据表,说白了就是 PHP 的项目业务简单到不足以启用领域模型相关的设计,进而我们可以思考 PHP 数据结构中惯用数组而非属性也是同样的道理。

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

分层设计

C# 工程结构

分层设计是老话题了,软件设计的核心就是自上而下,分而治之。图 2 是我之前架构的一个项目,自上而下,分别是应用层 Apps,服务层 Services,仓库 Repository,公共组件 Core。

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

数据层与业务层分离

数据抽象为数据访问,直接与数据存储进行交互。业务抽象为功能模块,业务组件,直接与用户交互。数据也就是图 1 中的 DAO,图 2 中的 Repository。业务也就是 Model。DAO 与 Model 并不存在严格的对应关系。

DAO 主要与数据库存储交互,不参与业务逻辑。

对外暴露的接口数据不仅仅是数据库字段的单纯映射,业务领域应该是用 Model 表示。

数据层和业务层分离的实践很简单。遵循两点:

第一代码目录分离

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

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

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

我们谈到基础设施,更多的会想到云计算领域的 PAAS,本文中把这个概念狭义的控制在软件层面的项目范围内。基础设施被定义为可以被抽象的,相对稳定的,对外提供服务的功能组件,对立,稳定,不易变化。英文单词 infrastructure。

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

业务组件

复制优于依赖

Alittle copyiing is better than a litter dependcy

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

怎么理解这句话?

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

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

PHP YII2 模块结构

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

总结

本文简要讨论了软件分层相关的经验和原则,软件分层,分而治之是软件工程的核心思想,从 OSI 参考模型,到 TCP/IP 应用模型,到云计算常见的业务形态,都在践行着这一思想。

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

end 2019 年 12 月

推荐阅读

系统化服务构建-调用链管理

退出功能需要网络支持吗?

系统服务化构建-跨域CROS

本文已同步到 公众号《图南日晟》欢迎关注

互联网技术服务

发布于: 12 小时前 阅读数: 4
用户头像

图南日晟

关注

还未添加个人签名 2017.11.15 加入

还未添加个人简介

评论

发布
暂无评论
系统化服务构建-软件工程分层