苏州优秀网站设计,安化建设局网站,网站关键词如何收录,信息化建设 调查报告 乡镇网站在企业内部网站的建设过程中#xff0c;网站后端最初采用传统的表模式的开发方式。这种方式极易导致站点的核心业务逻辑和业务规则分布在架构的各个层和对象中#xff0c;这使得系统业务逻辑的复用性不高。为了解决这个问题#xff0c;作者在后期的开发过程中引入了领域驱动… 在企业内部网站的建设过程中网站后端最初采用传统的表模式的开发方式。这种方式极易导致站点的核心业务逻辑和业务规则分布在架构的各个层和对象中这使得系统业务逻辑的复用性不高。为了解决这个问题作者在后期的开发过程中引入了领域驱动设计的开发方式把系统的业务逻辑独立建模、充分地复用并基于这些模型打造易于扩展的开发框架提高了整个团队开发业务逻辑的效率最终网站如期上线稳定运行至今。 目录
2 开发模式的应用
2.1 初期采用表模式开发模式
2.2 后期采用DDD开发模式来聚焦业务逻辑
3 结束语 2 开发模式的应用
2.1 初期采用表模式开发模式
在最初的开发过程中作者带领团队采用表模式开发系统也就是每个业务功能的开发都遵循如下的流程 1) 根据业务的需求分析得到数据表的字段把数据库表建好。 2) 通过ORM将数据库中的表映射成代码中的实体对象。 3) 在业务逻辑层根据功能的需要补充业务逻辑和规则操作实体对象进行数据的读取和持久化。
这种开发方式简单易行但是随着网站的功能逐渐增多逻辑越发地复杂如下问题逐渐显现出来 1) 通过ORM得到的实体对象都是贫血模型它们只有数据库映射的属性和字段并不具有具体的业务行为。 2) 因为没有明确的约束核心业务逻辑和业务规则非常容易从业务逻辑层扩散到其他层和对象中。有的跑到了帮助类中、有的跑到了存储过程里这导致了业务逻辑的复用性不高。
为了解决上述问题作者再次深入研究了上述的软件开发模式并决定引入DDD来开发和管理项目。
2.2 后期采用DDD开发模式来聚焦业务逻辑
使用DDD开发模式来开发和管理项目作者带领团队实践了如下的过程。
1) DDD战略设计 ①将整个应用程序域进行划分剥离各个子域在该项目中经过分析作者共拆分出账号管理、任务管理、积分管理、图书管理等子域。 ②对每个子域进行限界上下文的设计在每个限界上下文中保证任何一个对象模型的语义是确定的、无歧义的。 虽然两个User对象具有相同的名字但是它们是完整的用户对象在不同上下文中的投影是两个不同的对象。
在项目实施的过程中作者选择将子域和限界上下文一一对应独立部署在每个AppService中。 2) DDD战术设计 DDD战术设计的核心就是把核心业务逻辑集中放到一起组成领域层。其他层设计为依赖于该层。领域层中包含所有重要的领域模型包括聚合根、实体、值对象、领域事件、仓储、领域服务等。
①设计聚合根、实体和领域服务在该项目的领域层中最重要的对象就是聚合根和实体。它们完成了主要的业务逻辑。
使用聚合根还是实体在实践中一般都可以但是如果完成一个业务操作就一个主要的实体就可以了不需要其他相关实体的配合那么暴露这个实体给其他层就可以了。
比如Book这个实体不仅包含了所有图书的所有信息还包括增加封面、修改作者、增加点评等各种业务行为。
但是如果完成一个业务操作需要一个主要的实体配合上其他一些相关的实体才能完成那么就将主要的实体暴露成聚合根给其他层使用把相关的其他实体全部隐藏起来这些相关的实体的操作统统通过聚合根来暴露。
比如Task这个实体不仅包含了所有Task自身的信息和操作还包括其包含的子对象TaskItem实体的信息和各种操作所以 Task 实体就暴露为聚合根向外提供所有 Task 和TaskItem的相关操作其他层无法直接操作TaskItem对象以及其方法。如图6所示。 ②设计领域事件 该项目中非常常见的一个需求就是一个实体改变了需要通知其他的一些实体就行一些对应的变化。这种需求就需要通过事件模式来实现。
在项目中作者实现了一个EventBus作为通用的领域事件模型任何实体都可以挂接这个对象发布消息或关注感兴趣的消息并做出响应这个部分与通用的事件模型并没有太大的不同示意图如图7所示。 ③设计仓储 使用仓储模式可以很好地隔离数据库的操作和领域对象。
在领域层作者定义了各个仓储接口仓储与聚合根或实体一一对应包含对应的增删改查等操作它们是数据库操作的接口。
需要注意的是在领域层中只是定义了接口并没有具体的持久化的实现。具体的持久化工作放在了基础设施层中。
3) 其他层的一些细节 ①基础设施层 这里重点说明一下的是数据库持久化的选型。针对领域层提供的仓储接口作者实现时选择了使用Enti⁃ty Framework Core(以下简称EF Core) 作为基础框架。使用此类ORM框架大大简化了数据库的操作使用对象而不是SQL语句的方式可以避免很多语法上的错误有效地提升了代码的健壮性。
而且使用了EF Core的Code First的方式后项目只要使用EF Core的包命令就可以非常简单地根据实体对象的变更来创建和维护数据库。
②应用服务层 在该项目中应用服务层比较简单它实现了一个公用的AppService封装了公用的分页的逻辑。其他各项服务比如BookAppService都继承自该基类实现了自己的逻辑。
在各个服务中为了调用领域层的业务逻辑首先需要把前端传过来的输入数据传输对象(Data Transfer Object以下简称DTO) 转换成领域层的数据模型然后调用领域层的领域模型和基础设施层的对象完成功能最后再将结果转换成输出DTO返回给前端。
③后端接口层和前端表现层 接口层使用Restful Api去提供服务前端表现层使用Vue3.0实现展示不管是否使用DDD这些部分都是一样的不去多解释。 经过上述的分析、设计与重构最终得到如下新的架构如图8所示。 3 结束语
采用了DDD来开发和管理项目以后项目的业务逻辑沉淀到了领域层的领域对象中领域对象变成了包含业务逻辑的充血模型这样业务逻辑得到了复用程序的扩展性得到了保证。
此外由于存在清晰明确的分层和职责团队日常的开发效率得到了显著的提升。目前该站点已经上线并稳定地运行至今。
