领域驱动设计-从贫血模型到充血模型

背景

领域模型对象只是用来存储应用的数据。业务逻辑位于服务层中,管理域对象的数据。在服务层中,应用的每个实体对应一个服务类。这种模式大家是不是很熟悉,尤其是在中小项目或者项目刚启动的时候,都是怎么方便怎么来;没错,这就是贫血模型。

一般画风是这样的。

1、Web层:接收用户输入,将数据传至服务层;

2、服务层:处理业务逻辑、权限管理与授权,并与存储层通信;

using BQoolCommon.Interface.Repository.Dapper;
using BQoolCommon.Interface.Service;
using BQoolCommon.Models.BQoolCommon_SetMain;
using BQoolCommon.Models.Enum;
using BQoolCommon.Models.ViewModel;
using System;
using System.Collections.Generic;
using System.Configuration;

namespace BQoolCommon.Service
{
    public class UserPermissionService : IUserPermissionService
    {
        private readonly IInnerSiteMapDapperRep _innerSiteMapDapperRep;

        private readonly IInnerSiteMapService _innerSiteMapService;
        private readonly IAccountChannelRelService _accountChannelRelService;
        private readonly IUserMgmtService _userMgmtService;

        public UserPermissionService(
            IInnerSiteMapDapperRep innerSiteMapDapperRep,
            IInnerSiteMapService innerSiteMapService,
            IAccountChannelRelService accountChannelRelService,
            IUserMgmtService userMgmtService)
        {
            _innerSiteMapDapperRep = innerSiteMapDapperRep;
            _innerSiteMapService = innerSiteMapService;
            _accountChannelRelService = accountChannelRelService;
            _userMgmtService = userMgmtService;
        }
.................................................

3、存储层:与数据库进行通信,对数据进行持久化;

using System.Linq;
using BQoolCommon.Interface.Factory;
using BQoolCommon.Interface.Repository.Entity;
using BQoolCommon.Models.BQoolCommon_SetMain;
using BQoolCommon.Models.ViewModel;

namespace BQoolCommon.Repository.Entity
{
    public class WeChatSubscribeEntityRep : GenericEntityRep<WeChat_Subscribe>, IWeChatSubscribeEntityRep
    {
        public WeChatSubscribeEntityRep(IBqoolSetMainDbContextFactory factory) : base(factory)
        {
        }
    }
}

问题窥探

问题出在了服务层,他承受了太多的职责,像业务逻辑、权限检查等等,这违反了单一职责原则,并产生了大量的依赖。当业务复杂度上升时,服务层所包含的代码将会非常庞大和复杂。服务层需要包含应用逻辑、用户会话的管理;领域层应该包含业务逻辑,可以处理与业务相关的会话状态。

改进思路

我们需要将业务逻辑从服务层移动到领域模型中,这样的好处是,服务层可以只负责应用逻辑(如数据有效性验证、授权检查、开始结束事务等),领域模型可以专门负责其相关的业务逻辑。以电商系统来举例,架构设计时完全可以针对订单、商品、库存等多个领域模型进行建模,相关的业务可以分别放到不同的领域模型中,一些很有可能重复的业务代码都会被集中到一处,从而降低了复制-粘贴的可能性,这就是充血模型。

影响

充血模型将服务类变得更小,使之只负责单一的职责。例如商品的CRUD和其他操作,就可以将其放到两个不同的服务类中,一个负责商品的CRUD操作,另外一个负责与商品相关的其他操作。这样就能使服务类变得小巧、松散、可测试了,同时还能降低其他人理解与重用的成本。

总结

1、从规范和长远来看肯定是充血模型合适些。

2、但是如果只是小项目、求快的话,当然是开发成本低的贫血模型。

(0)

相关推荐

  • 30种高品质思维模型:19

    ● 我们往往想要朝着目标前进,而不是避免负面后果--这是情不自禁的,是我们从小被灌输的思维模式,当然也未必是错的.本书其他章节讲的是正向的思维模型,而本章介绍的是反向思考的思维模型,教你怎样只专注一件 ...

  • 三 领域驱动设计-运用领域模型-绑定模型和实现

    领域驱动设计-运用领域模型-绑定模型和实现 聪明的项目组成员花费了几个月的时间进行仔细的研究并且开发出了详尽的领域模型(类图).然而对类图研究不能让我深入地了解该应用程序的代码和设计,这让我备感困扰. ...

  • 如何运用领域驱动设计 - 聚合

    目录 概述 何为聚合 演化案例 发现实体关系 开始划分边界吧 选取一个聚合根 通过聚合根保护你的内部对象 聚合的一些特性 通过ID引用 聚合真的是不变的吗 小的聚合 一致性 总结 概述 在前几篇的博文 ...

  • 如何运用领域驱动设计 - 工作单元

    新年伊始,祝大家喜乐如意,爱和幸福"鼠"不尽!♫. ♪♬.♩♫ 概述 在上一篇 <如何运用领域驱动设计 - 存储库> 的文章中,我们讲述了有关仓储的概念和使用规范.仓储 ...

  • 领域驱动设计适用于军用软件开发吗?

    领域驱动设计这个概念提出已经超过10年. 近些年来,国内已经有一些互联网公司开始试水领域驱动设计.作为军用软件开发来说,领域驱动设计适合吗? 领域驱动设计自其诞生之日起就是为了解决软件的复杂性的.领域 ...

  • 为什么说领域驱动设计可以提升软件的质量水平?

    领域驱动设计是一套方法论,指导我们将复杂问题进行拆分.拆分出各个子系统间的关联以及是如何运转的,帮助我们解决大型的复杂系统在落地中遇到的问题. 在学习领域驱动设计的过程中我越来越感觉到领域驱动设计可以 ...

  • DDD领域驱动设计真就一文不值?

    在互联网快速发展的这几年来,微服务.领域驱动设计等已经非常流行,并成为目前软件开发行业的主流趋势. 大家都知道,微服务划分的一个重要理论基础就是领域驱动设计.但由于 DDD 门槛高.概念多,体系庞大又 ...

  • 深入理解领域驱动设计中的聚合

    聚合模式是 DDD 的模式结构中较为难于理解的一个,也是 DDD 学习曲线中的一个关键障碍.合理地设计聚合,能清晰地表述业务一致性,也更容易带来清晰的实现,设计不合理的聚合,甚至在设计中没有聚合的概念 ...

  • 领域驱动设计(DDD)理论与方法

    DDD由来与优势 软件架构设计的真正目的是解决软件复杂度带来的问题,软件复杂度由来主要由三方面:高并发场景下的对软件高性能要求.业务场景对软件高可用要求.持续变化的业务以及业务扩张和增加需求对软件扩展 ...

  • 领域驱动设计(DDD)在爱奇艺打赏业务的实践

    领域驱动设计(Domain-Driven Design,以下简称DDD)思潮的形成要追述到30几年前,17年前,Eirc Evans定义了领域驱动设计的概念.DDD一直为传统行业的软件工程师提供软件设 ...