DDD领域实体存在的有什么意图

首先领域实体的功能
1. 领域实体有维护领域实体的关系功能，比如Order维护着与OrderDetail的关系
2. 领域实体是复杂的逻辑拥有者，比如Order的CalculateTotal问题。
也就是在DDD驱动开发中领域实体是数据属性与行为的是内聚的。

问题的导出：前台客户端调用后台的是一种就是调用后台的数据，另外就是前台调用后台的业务逻辑。

领域实体数据属性问题：在企业应用程序都是领域实体的数据属性都是需要在实施的时候根据企业的需要进行定制，那么在编程语言里面定义的属性都是基本的简单属性，这样领域实体里面的属性就只有Name，Description，CreateTime，UpdateTime，CreateUser，UpdateUser等。
这里暴露出一个问题也就是如何处理领域实体的属性可定制性需求（根据具体客户具体定义）？

对于调用后台的数据而言，领域实体和DataObject没有区别，而且由于领域实体的属性是在静态定义的，而客户需要自己的属性集。所以领域实体不能很好解决这个问题。

 

业务逻辑存在于领域实体中：领域实体的复杂业务逻辑是可以使用Service服务来实现的，这样领域实体又变成了贫血模型。而且前台调用后台的逻辑首当其冲的编程这些Service服务类。当然这里逻辑存在与领域实体的理由是职责分离，关注点分离等。也就是Service服务类把一些职责委派给领域实体来完成。
比如OrderService Fullfill方法牵涉到认证、授权、然后创建新的订单领域实体等等。但是我们主要到OrderService Fullfill方法相对是比较稳定的，如果不稳定的话可以用工作流来完成。从方面来看领域实体是为业务逻辑的载体而存在。

 

领域实体如何满足企业领域实体属性自定义的需求？
这个问题主要有两种解决方法，采用Sharepoint类似的方案，所以的实体属性都是可以自定义，但是这个时候就没有领域实体定义因此业务逻辑不能存在于领域实体，因此业务逻辑存在与工作流中。

另外一种解决方法就是领域实体不但包含简单属性并包含业务逻辑，而且包含自定义属性API。

不知道上面两种方案具体应用怎么样，或者有不同的解决方法。欢迎大家发表自己的看法。