领域Model?

前言

领域驱动设计里有很多东西,我们可以应用在各种各样的开发模式里,所以接下来说的一些东西,我们可以部分使用。

说道领域驱动的领域,大家肯定就要开始说Bounded Context,聚合,聚合根,容易让大家搞糊涂。 我觉得先抛开这些概念,后面再来说如何设计聚合,先简单来说。

模型

过去,我们在多层设计里定义了很多Model, 数据库的Model(DB Entity), 然后为了不依赖数据库,我们有设计了业务的Domain Model, 同时我们又设计了ViewModel, 这样一般也没什么问题,职责也很清晰。但是有几个问题

  1. 我们要做很多的模型转换,转入转出。当然我们可以用AutoMapper来但是AutoMapper的性能实在难以恭维,大家可以在网上搜索AutoMapper performance.
  2. 领域模型成了一个单纯的DTO了。

领域模型

首先我们要看领域,就是我们尽量把业务聚合到一个领域里,比如我们要做一个功能,可以看到用户每一次的登录日志,那个这个登录日志其实就是属于用户这个领域里。

其次我们看模型,原来我们的模型都是只有属性,也就是贫血模型,贫血的意思就是没有行为,像木乃伊一样,但是实际上领域是我们要完成业务的最主要的地方,我们希望领域能够自制,也就是领域自己管理自己。

示例

比如有一个Employee, 他的状态有Active, Pending, DeActive, 业务上是Pending只能改为Active.

1
2
3
4
5
6
7
8
9
10
    public class Employee : Entity
    {
        public Name Name { get; set; }

        public EmployeeStatus EmployeeStatus { get; set; }

    }

如果是贫血的Employee模型,我们往往代码如下


	public class EmployeeService : IEmployeeService
    {
        private readonly IUnitOfWorkFactory _unitOfWorkFactory;
        private readonly IEmployeeRepository _employeeRepository;

        public EmployeeService(IUnitOfWorkFactory unitOfWorkFactory, IEmployeeRepository employeeRepository)
        {
            _unitOfWorkFactory = unitOfWorkFactory;
            _employeeRepository = employeeRepository;
        }

        public void ChangeStatus(EmployeeStatus status, Guid employeeId)
        {
            using (var unitOfWork = _unitOfWorkFactory.GetCurrentUnitOfWork())
            {
                var employee = _employeeRepository.GetById(employeeId);
                employee.EmployeeStatus = status;

                unitOfWork.Commit();
            }
        }
    }

	

但是上面的代码的问题就是领域没有自治,本来修改我的状态是我的事,你能不能修改,外面随意修改我的状态是很危险的,比如Pending状态只能改为Active状态。 所以如果不是贫血的模型,我们代码就会这样,让领域自己来管理

	public class Employee : Entity
    {

        public UserId UserId { get; private set; }
        public EmployeeStatus EmployeeStatus { get; private set; }

        public void ChangeStatus(EmployeeStatus status)
        {
            if (this.EmployeeStatus == EmployeeStatus.Pending && status != EmployeeStatus.Active)
            {
                throw new Exception("Only can Active when status is pending");
            }

            this.EmployeeStatus = status;
        }

    }

	public class EmployeeService : IEmployeeService
    {
        private readonly IUnitOfWorkFactory _unitOfWorkFactory;
        private readonly IEmployeeRepository _employeeRepository;

        public EmployeeService(IUnitOfWorkFactory unitOfWorkFactory, IEmployeeRepository employeeRepository)
        {
            _unitOfWorkFactory = unitOfWorkFactory;
            _employeeRepository = employeeRepository;
        }

        public void ChangeStatus(EmployeeStatus status, Guid employeeId)
        {
            using (var unitOfWork = _unitOfWorkFactory.GetCurrentUnitOfWork())
            {
                var employee = _employeeRepository.GetById(employeeId);
                employee.ChangeStatus(status);

                unitOfWork.Commit();
            }
        }
    }
    

因此可以看出,我们把业务代码尽量写在领域里让领域自治。

后记

其实领域驱动设计最难的就是设计领域(Domain), 也就是后面会说到的AggregateRoot 聚合,但是我想我们先让领域不再贫血,这样在传统的多层设计,数据驱动等架构都可以使用这种模式。

时间: 2024-10-10 05:19:32

领域Model?的相关文章

DDD领域驱动设计仓储Repository

DDD领域驱动设计初探(二):仓储Repository(上) 前言:上篇介绍了DDD设计Demo里面的聚合划分以及实体和聚合根的设计,这章继续来说说DDD里面最具争议的话题之一的仓储Repository,为什么Repository会有这么大的争议,博主认为主要原因无非以下两点:一是Repository的真实意图没有理解清楚,导致设计的紊乱,随着项目的横向和纵向扩展,到最后越来越难维护:二是赶时髦的为了“模式”而“模式”,仓储并非适用于所有项目,这就像没有任何一种架构能解决所有的设计难题一样.本篇

C#进阶系列——DDD领域驱动设计初探(二):仓储Repository(上)

前言:上篇介绍了DDD设计Demo里面的聚合划分以及实体和聚合根的设计,这章继续来说说DDD里面最具争议的话题之一的仓储Repository,为什么Repository会有这么大的争议,博主认为主要原因无非以下两点:一是Repository的真实意图没有理解清楚,导致设计的紊乱,随着项目的横向和纵向扩展,到最后越来越难维护:二是赶时髦的为了“模式”而“模式”,仓储并非适用于所有项目,这就像没有任何一种架构能解决所有的设计难题一样.本篇通过这个设计的Demo来谈谈博主对仓储的理解,有不对的地方还望

WCF搭建

WCF搭建 前言:前面三篇分享了下DDD里面的两个主要特性:聚合和仓储.领域层的搭建基本完成,当然还涉及到领域事件和领域服务的部分,后面再项目搭建的过程中慢慢引入,博主的思路是先将整个架构走通,然后一步一步来添加相关元素,使架构慢慢变得丰满.这篇打算分享下应用层的搭建.根据DDD的设计原则,应用层不包含任何领域逻辑,它主要的作用是协调任务,或者叫调度任务,维护应用程序状态.根据博主的理解,应用层是用来隔离领域层的,假设没有应用层,那么我们的界面层可以直接调用领域层的逻辑,也就是说可以直接访问领域

MVP, MVC, MVVM, 傻傻分不清楚~

1 简介 英文原文:MVC vs. MVP vs. MVVM 三者的目的都是分离关注,使得UI更容易变换(从Winform变为Webform),使得UI更容易进行单元测试. 2 MVC/MVP 2.1 MVC 1.View接受用户的交互请求 2.View将请求转交给Controller 3.Controller操作Model进行数据更新 4.数据更新之后,Model通知View数据变化 5.View显示更新之后的数据 View和Controller使用Strategy模式实现,View使用Com

Web层的搭建

Web层的搭建 前言:好久没更新博客了,每天被该死的业务缠身,今天正好一个模块完成了,继续来完善我们的代码.之前的六篇完成了领域层.应用层.以及基础结构层的部分代码,这篇打算搭建下UI层的代码. DDD领域驱动设计初探系列文章: C#进阶系列——DDD领域驱动设计初探(一):聚合 C#进阶系列——DDD领域驱动设计初探(二):仓储Repository(上) C#进阶系列——DDD领域驱动设计初探(三):仓储Repository(下) C#进阶系列——DDD领域驱动设计初探(四):WCF搭建 C#

让AutoMapper在你的项目里飞一会儿(转)

出处:http://www.cnblogs.com/WeiGe/p/3835523.html 先说说DTO DTO是个什么东东? DTO(Data Transfer Object)就是数据传输对象,说白了就是一个对象,只不过里边全是数据而已. 为什么要用DTO? 1.DTO更注重数据,对领域对象进行合理封装,从而不会将领域对象的行为过分暴露给表现层 2.DTO是面向UI的需求而设计的,而领域模型是面向业务而设计的.因此DTO更适合于和表现层的交互,通过DTO我们实现了表现层与领域Model之间的

AutoMapper使用

AutoMapper使用 前言:前篇搭建了下WCF的代码,就提到了DTO的概念,对于为什么要有这么一个DTO的对象,上章可能对于这点不太详尽,在此不厌其烦再来提提它的作用: 从安全上面考虑,领域Model都带有领域业务,让Client端引用Domain Model就意味着Client端可以绕过应用层直接完成业务逻辑的调用,这样是一种不安全的机制. 从对象传递效率上面考虑,领域Model带有业务,而这些业务一般对于UI层是没有意义的,所以带有业务的model传递起来会加重网络负担. 网上还说了DT

让AutoMapper在你的项目里飞一会儿

先说说DTO DTO是个什么东东? DTO(Data Transfer Object)就是数据传输对象,说白了就是一个对象,只不过里边全是数据而已. 为什么要用DTO? 1.DTO更注重数据,对领域对象进行合理封装,从而不会将领域对象的行为过分暴露给表现层 2.DTO是面向UI的需求而设计的,而领域模型是面向业务而设计的.因此DTO更适合于和表现层的交互,通过DTO我们实现了表现层与领域Model之间的解耦,因此改动领域Model不会影响UI层 3.DTO说白了就是数据而已,不包含任何的业务逻辑

angular中的MVVM模式

在开始介绍angular原理之前,我们有必要先了解下mvvm模式在angular中运用.虽然在angular社区一直将angular统称为前端MVC框架,同时angular团队也称它为MVW(Whatever)框架,但angular框架整体上更接近MVVM模式.下面是Igor Minar发布在Google+ https://plus.google.com/+IgorMinar/posts/DRUAkZmXjNV的文章内容: MVC vs MVVM vs MVP. What a controver