2012-07-09 07:20 "@gameboyLV"的内容
当然是,比如网站通行证的注册,需要注册论坛,调用其他第三方系统的API,如果您将这些业务全部封装在USER的DOMAIN里,肯定是不合适的。假如第三方的API变更,那么整个USER的DOMAIN也无法运转了。

放在服务里就好多了,可以随时 ...

“放在服务里”这个“服务”是指领域服务?还是应用层?
我先理解成应用层吧。
如果是不同的子系统,那么在应用层,我觉得挺好。可是如果是子系统内部,那么应该是内聚的。放应用层我觉得将业务分散了,放领域实体的类中又觉得就单个领域实体对其他外部依赖过多,放领域服务中是个相对好的办法,可是领域服务在实现上又类似事物脚本,只是个放在了领域层的事物脚本。

2012-07-09 08:40 "@SpeedVan"的内容
场景思维可能更好定位实体位置,实体方法(行为)只会影响自身,交互行为应该放在场景中。

这种思维可以很好跟Actor结合:每个Actor收到消息也就只能改变自身,不能直接对其他Actor进行修改,而相关的消息的组合可以看作场景的剧本。 ...

您说的“场景”是什么模式?在代码实现是什么?有相关资料吗?我去学习一下。

2012-07-09 13:00 "@xxooxx"的内容
您说的“场景”是什么模式?在代码实现是什么?有相关资料吗?我去学习一下。 ...

这思维在JDON上有作讨论,可作相关查找,关键字:场景,DCI。

这是从思考物转向思考事。场景一词似剧本中的场景,要做什么怎么做都决定好,参与角色的行为只对自身影响。

例如转账:
转账是两个账号进行交互,转账场景决定了转出账号的金额移到转入账号,而转出和转入是账号自身决定,也只对自身有影响。

代码方面没有标准,因为这提出的时候只是思想。