贫血领域模型和事务脚本的区别

业务逻辑放在服务中，服务变成了事务脚本，一般在服务中使用JTA或JDBC数据库锁或2PC两段事务保证业务逻辑的事务性。

贫血的领域模型是个状态模型，它上面的方法只是用来确保模型实例级别的状态合法性的。一个在模型实例级别合法的模型实例不一定在我们的系统中是合法的，比如它的标识与别人重复了它就在该类型的模型实例集合中不合法。
状态模型无法修改只能替换。在数据库中记录看似是可以修改的，其实都是在替换，是局部替换那些变更字段。
贫血的状态模型中的用来确保模型实例级别状态合法性的逻辑我觉得也属于领域逻辑。领域逻辑是和我们的系统一样分层管理的，领域服务中的是是领域逻辑，Actor中的是领域逻辑……甚至展示层逻辑中验证输入合法性的逻辑也是领域逻辑，当然在内层的服务层和贫血模型层也有重复的验证，系统将某些逻辑从内层投影到外层去执行只是为了减少对内层的无效请求和提高对用户的响应速度。
[该贴被anycmd于2015-01-14 11:38修改过]

简单地说：业务逻辑放在服务中，服务就是事务脚本。

业务逻辑放在MVC控制器中，控制器就是事务脚本。

原定义：Organizes business logic by procedures where each procedure handles a single request from the presentation.

同意。但是此处的ViewModel和Dto从实现上来说是贫血的，但上面这些理由已经足够说服它有存在的必要（现实中也如此）。依这个构造出来的领域部分仍然是充血的领域模型（因为领域对象是富行为的），没有服务层的存在或者服务层很薄。我倒觉得ViewModel和Dto属于应用服务层的一部分。这个和贫血的领域模型我觉得不同。

如果我把所有数据相关的东西都 json 化呢，这样数据部分只是一个 map，举例
class Admin {
Map json;
}
class User {
Map json;
}
数据部分完成了。现在我们赋予管理员的一个行为：给用户加分（包括负分）
class Admin {
Map json;
void scoreUser(User user, int score) {
if(checkRole(user))
user.json.score+=score;
else
throw new BusinessException("没有权限操作当前用户");
}
private boolean checkRole(User user) {
// 隶属于管理员能管理的组，才能操作这个用户
return admin.groups.contains(user.group);
}
}
我认为这个行为就是一种有血模式，到这里管理员已经完成了加分操作，后续的将 user 的新状态持久到 db 由另一个服务完成。如果是失血模式，会在某个 Server 中操作：
class XXXServer {
void scoreUser(User user, int score) {
// find user
// find admin
// check role
user.json.score+=score;
// save user
}
}
[该贴被freebox于2015-02-11 08:54修改过]