2020年春节第一天，早早醒来，出去晨跑一下，目前武汉以及周边的疫情处于红色报警状态，今年春节宅家是最安全的做法。闲暇之余，还需要探索技术，跑步中忽然想到了【忒修斯之船】的小故事，感觉很值得玩味，也可以结合程序再次重温一下，DDD 系列之【实体建模】的一些皮毛见解。
所谓的【忒修斯之船】亦称为忒修斯悖论，是一种有关身份更替的悖论。假定某物体的构成要素被置换后，但它依旧是原来的物体吗？公元1世纪的时候普鲁塔克提出一个问题：如果忒修斯的船上的木头被逐渐替换，直到所有的木头都不是原来的木头，那这艘船还是原来的那艘船吗？因此这类问题现在被称作“忒修斯之船”的问题。其实本质就是 一个物体 整体与局部之间的辩证法，一般而言，系统的整体大于局部。
一般而言，我们认为无论【忒修斯】的【船】被替换过多少的零件（木头），船还是那艘船，不会因为木头的替换就有所改变。那么如果被替换的零件都得到很好的保存，而且用替换的零件也组装了一条与【忒修斯之船】一样的船。姑且认为是【旧忒修斯之船】，这个时候，出现了问题的：到底那艘船才是真正的【忒修斯之船】呢？【忒修斯】不可能同时拥有两艘一样的船啊！
涉及到我们今天要谈到的话题，DDD领域下众多环节中的【实体】建模，受启发于上面的哲学小故事，当我们尝试采用【实体】模式对某一业务进行的时候，需要为该【实体】确立唯一的标识，保证未来的一段时间内，可以通过该标识来确定事物的唯一性，其次就是那些属性是构成【实体】不变的特性，也要进行列举，这些不变的属性，才让我们对不同的【实体】加以甄别，以便区分彼此。通常而言，【实体】的唯一性我们一般采用数据库【主键】模式实现，在我看来，这种唯一标识只能算作是一种委派，例如自增长ID、雪花算法、以及UUID等，他们可以保证ID的唯一性，但是我们无法通过【唯一标识】来确认他到底属于什么【实体】，在实际的建模过程中，【实体】的唯一标识也许才是我们真的需要自己论证的，采用什么样的编码学进行编码才可以更好的展示【实体】呢？留给读者自己思考。如果是对自然人做【实体】建模，证件类型+证件号码，则可作为【实体】的唯一表述。
其次则是构成【实体】的属性，这些属性的存在构成了【实体】的本源。这里尤其是指那些不可改变的【属性】，他们也成为【实体】进行相等性判断的关键，但我们尝试修改该【实体】时，这些属性是被排除在外的（录错的情况除外），这些不可修改的【属性】也算是构成【实体】建模的重要组成部分，例如宝马与奥迪之间的区别，大家是很容易对其进行区分的，【实体】自身的一些特性决定在这个世界的独立性与唯一性。在实际操作中，由于我们的业务关注点不同，对业务建模的重点也不同，但建模的思路与方法一致的，如针对“汽车”建模而言，汽车至少商对汽车的建模与运输商对汽车的建模肯定是不尽相同的，但是这个并不影响大家对于如何建模的思考。建模的目的是为了更好的实现业务本身，这是建模的目的。
再次考虑【实体】一旦被我们建模后，肯定会在不同的场合被调用或者被用来装配，使用【实体】的程序员可能是他的创建者或者是别的程序员，这时【实体】建模的显得比较有意义了，不在是多此一举的代码了（【实体】建模的过程，对于一些快速开发框架是不友好的，例如 ORM框架，他们只能识别getter 与 setter 等），因为通过解读【实体】（代码阅读），使用者可以明确的知道【实体】的唯一标识，那些属性该【实体】的固有属性，是不可以为修改的等。那些固有的属性 ，至少需要在【实体】的构造函数内完成赋值，而且不应该有 setter方法对其进行修改，谨慎一些应该用 final 关键字来修饰.......这些则是属于编程上的一些技巧。
好了，断断续续的再次讨论【实体】的建模的一些方法论与思考的纬度，他是对实体建模的一种方法论层面的思考，不涉及具体的开发语言自身，可以说适合各种语言。有人说【实体】建模不适合前端技术（狭义的定义为JS 们），我不这样认可，计算机一直在模拟人类现实，至少是被模拟的场景，我觉得就可以进行建模处理。 好了 ，祝大家 鼠年快乐........ 也祝自己在新的一年，能够顺顺利利~~~ 借用一句名言：只争朝夕，不负韶华
来源：oschina
链接：https://my.oschina.net/qfhxj/blog/3161423