个人以为，DDD中提倡的统一建模语言，完全可以UML这个统一语言为平台，大家在同一个语言基础上交流沟通，当然，对于简单案例，也可以是CRC或Story等统一表达方式，不过UML要跟全面更专业一点。

DDD只是强调了方向，至于如何到达方向并没有细说，这就要结合其他已有的OO分析设计经验来丰富完善。

1.业务领域的建模

2.代码实现

ddd追求的是两者的统一，无论是用uml实现还是直接在纸上实现都是对象之间的关系

而ddd中很重要的一点就是如何划分实体、值对象、service，其他部分如factory、repository等方面我们还是比较好区分，因为这些部分要么是为了封装聚合根的创建复杂性，要么是跟底层的缓存、持久层耦合实现的

我们现在的实体、值对象、service太模糊了，这是我们最头大的地方。

是不是值得跟踪的那些对象就应该是实体，那么这些实体的存在周期，又该如何在系统中确认呢？

我现在对这个生命周期比较纠结，我们就是从数据库获取对象，然后提交到domain里面去处理（这里就比较郁闷，扔给facade或service去处理了），到底怎么做就是判别这个对象消逝了，怎样就算是存在了？

我的做法是把这个对象从Repository创建出来后，就放在内存中，其实是放在缓存中。

因为这个“取放入内存”这个行为是可重复执行的，只要涉及到使用这个实体，我就先通过"取放入内存"这个行为来获得这个实体对象。

也就是说实体对象是即用即取的，实体对象的生命周期应该假设是Application级别的，可被认为是常驻内存的，不知你为什么要判断实体的生命周期

要分清哪些对象是实体或值对象，我觉得有两步可以参考：

1、从需求、业务分析入手，有业务ID（非数据库ID）的对象是实体，否则先暂时定为值对象

2、从类-类之间的关系入手，如果有一个类的对象是要依赖其父对象的存在而存在的，那么可暂时将其定为值对象。

3、值对象的信息一般在其生命周期内是不可变的

另外，实体或值对象的确定是一个随着分析和设计不断迭代而逐步清晰的过程，并且是根业务需求/业务场景密切相关的。比如客户、地址这两个类，在不同的系统中会有不同情况，举两个很粗的例子：

1、在一个电子商务系统中，有可能客户是实体，而地址是值对象。因为从分析得出地址不会单独存在，而是要依附在某个客户上，并且没有任何功能会从地址对象为起点。

2、在一个配送系统中，有可能客户是值对象，而地址是实体。因为配送系统关心的是货物和配送跟踪，而至于谁收货物则不是系统关心的东西。