如何运用DDD - 实体

概述

本文将介绍领域驱动设计（DDD）战shu模式中另一个常见且非常重要的概念 - 实体。相对战shu模式中其他的一些概念（例如 值对象、领域服务等）来说，实体应该比较容易让人理解和运用。但是我们如何去发现所在领域中的实体呢？如何保证建立的实体是富含行为的？实体运用时又有那些注意的细节呢？本文将从不同的角度来带大家重新认识一下“实体”这个概念，并且给出相应的代码片段（本教程的代码片段都使用的是C#,后期的实战项目也是基于 DotNet Core 平台）。

何为实体

按照国际惯例呢，我们先吹牛。直接来看看原著《领域驱动设计:软件核心复杂性应对之道》 中对实体的解释：

实体(Entity，又称为Reference Object) 很多对象不是通过他们的属性定义的，而是通过一连串的连续事件和标识定义的。

主要由标识定义的对象被称为ENTITY。

上面的两句话多读了几遍，好像这个定义还是能够理解嘛。不像上一篇文章 如何运用DDD - 值对象 中的概念那么深奥。说白了，上面就是说明了一个问题，只要你所发现的事物/对象有一个唯一的标识，那么它可能就是实体了。而唯一的标识就是我们代码中快写烂了的那个ID。

似曾相识

来想一下，我们在以传统的设计思路和开发过程中，我们会在什么情况下为一个对象赋予一个ID呢？给它赋予这个ID的作用呢？一般来说我们的目的无非就是 1、为了区分本对象，如果是在数据库中，那就是为了区分本条数据和另外一条数据，而这个ID也往往作为主键而存在 2、加个索引吧，来提升关联查找速度。所以我们如果将数据库中的表映射到我们的代码中以类的形式呈现的时候，它可能就是这个样子：

//旅行的行程publicclassItinerary{publicintID {get;set; }//参加本次旅行的人员publicList Participants {get;set; }//旅行的地点publicList Places {get;set; }//关于该行程的备注笔记信息publicstringNote {get;set; }//旅行开始时间publicDateTime StartTime {get;set; }//旅行开始时间publicDateTime? EndTime {get;set; }//旅行的状态(进行中 or 已完成)publicintStatus {get;set; }}

上面的代码对我们来说应该丝毫都不陌生，我们建立了一个旅行行程的类，至于为什么我们会选取旅行行程，而不是各个博客都出现的以订单啊电商平台作为案例。那是因为在后期我们会一起动手来实现一个旅行记账的微信小程序，并且借助于我们慢慢所学习到的DDD理论作为基础，开发属于我们自己的领域驱动框架，当然项目也是基于 DotNet Core（版本应该是3.x）。

好了，还是回到我们这个例子，来思考一下ID出现的目的。你可能会说：“这还不简单吗？老夫纵横代码界多年，你现在还来问我这个问题！ID肯定是用来区分的呀，行程千千万万，我要找出这一条行程肯定需要这个ID了呀。” 是的，这是一个毫无争议的问题。我们需要一个唯一的身份标识来区别对象之间的差异。DDD中实体的这一点与我们平时所接触的类的ID有异曲同工之妙，所以本文开头也说了实体可能是相对其他战shu概念最为让人理解的。