本文主要讨论软件项目开发中的工程化，涉及软件分层、业务分离等概念。软件工程通常是指用工程原理、原理和方法来指导软件开发，解决软件危机。狭义工程概念本文所涉及的工程概念为狭义工程。这里给工程下一个定义：软件开发中组织源代码的方式，用来实现软件开发需求，最终交付给软件运行。工程与语言无关，或者说每一种语言都涉及工程，不同的语言根据语言特点有不同的侧重点。本文来源于一张图片。图1是《极客时间》一门微课中的Go项目工程图，印证了我这些年在开发设计中关于项目创建的一些想法。说明如下。业务领域模型首先，Model是业务领域的概念，对应的是业务模型，而不是数据库字段或数据库字段的映射。这在PHP中尤其容易被误解。大家认为模型就是数据库的表映射。为什么Model在PHP从业者眼中代表的是数据表呢？说白了，PHP的项目业务过于简单，无法启用领域模型相关的设计，然后我们可以思考同样的原因，在PHP数据结构中使用数组而不是属性。想想这几个例子，客户和用户，账户和用户，通行证和用户，在程序中是怎么定义的，辅以常见的产品描述？这些是典型的业务领域。分层设计分层设计是一个古老的话题，软件设计的核心是自上而下、分而治之。图2是我之前架构的一个项目。从上到下分别是应用层Apps、服务层Services、仓库Repository、公共组件Core。理论上是这样，但实践中的难点在于区分的粒度和衡量标准。以下是一些参考：数据层与业务层分离。数据被抽象为数据访问，直接与数据存储交互。将业务抽象为功能模块和业务组件，直接与用户交互。数据是图1中的DAO和图2中的存储库。业务是模型。DAO和Model之间没有严格的对应关系。DAO主要与数据库存储交互，不参与业务逻辑。对外暴露的接口数据不仅仅是数据库字段的简单映射，业务领域应该用Model来表示。数据层和业务层分离的做法很简单。遵循两点：第一代码目录与第二数据层分离获取数据时，只需要获取数据，不需要处理逻辑，不包括大小比较，数据类型判断等，抛给上层层。说起来容易，做起来难，落实了才算数。业务组件和基础设施层的分离当我们谈论基础设施时，我们更多地想到云计算领域的PaaS。在本文中，这个概念被狭义地控制在软件级别的项目范围内。基础设施被定义为可抽象的、相对稳定的、对外提供服务的功能组件。它是相反的，稳定的，不易改变的。英语单词基础设施。相反，业务组件（图3中的组件）被定义为可变的、灵活的功能集合。从层次结构的角度来看，业务组件高于基础设施。复制胜于依赖一点点复制胜于垃圾依赖有时候并不需要优先追求共享代码，应该有一些复制冗余。通用意味着多次使用，依赖耦合。复制虽然增加了复制的成本，但它是独立的、免费的。你怎么理解这句话？我们以YII2项目为例。官方推荐的Advanced模板中有一个公共项目common，那么我们是不是要把项目中可以共享的所有数据层都放到common中呢？如上图，如果passport和admin模块都涉及到同一个User表，基于复制优于依赖的原则，不需要共用一个User类，可以存储为两个User类分开，由命名空间分隔。而且，由于模块不同，即使是同一个数据表对象，相关的数据操作也会不同。总结本文简要讨论软件分层相关的经验和原则。软件分层和分治是软件工程的核心思想。从OSI参考模型，到TCP/IP应用模型，再到云计算的常见业务形态，都在实践中。有了这个想法。如果您有任何问题或建议，欢迎留言分享。2019年12月结束
