本文介绍了业务逻辑层的重要性，它介于数据库和服务层之间，负责业务对象的CRUD操作。内容涵盖领域对象模型、领域实体、业务规则和验证规则。文章讨论了事务脚本、表模式、活动记录模式和领域驱动设计四种业务层模式，分析了各自的优缺点和适用场景。强调领域模型关注问题领域，与数据库保持独立，但需要ORM框架协助映射。架构师需根据项目需求选择合适的模式。
业务逻辑层是专门处理软件业务需求的一层，处于数据库之上，服务层之下，完成一些列对Domain Object的CRUD，作为一组微服务提供给服务层来组织在暴露给表现层，如库存检查，用法合法性检查，订单创建。
业务逻辑层包含领域对象模型，领域实体，业务规则，验证规则，业务流程。1：领域对象模型为系统结构描述，包含实体功能描述，实体之间的关系。领域模型处于天生的复杂性:2：领域实体：业务层是一些操作业务对象（BO）的处理。业务对象包含数据和行为，是一个完整的业务对象。其不同于上节架构设计中服务层的简单理解提到的数据迁移对象（dto），对于dto存在数据的，不存在行为，dto是bo（ddd中又称do）的子集，负责与特定界面需求的扁平化实体，dto仅仅是一个数据载体，需要跨越应用程序边界，而业务对象则不会存在复制迁移，往往一个业务对象存在一个或者多个数据迁移对象。3:业务最大的逻辑就在处理一些列现实世界的规则，这也是软件中最容易变化的部分，这里通常会出现我们众多的if-else或者switch-case的地方。也这因为如果说以个人觉得在我们的项目最应该关系和分离需求的层次。4：验证规则：业务规则很大程度上也是对对象的数据验证，验证业务对象的当前数据状态。我觉得在每个业务对象上都应该存在一个对外部对象暴露的验证接口，可以考虑微软企业库的VAB
最低0.47元/天 解锁文章
扫一扫
697
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
