[该贴被linychuo于2011-10-27 22:03修改过]
2011年10月27日 15:41 "@linychuo"的内容
我按照四色原型来建模 ...
图中没有显示四色啊，四个角色要标注出来，另外，从你的图看出，都是名词表结构而已，比如手机验证码，在OO分析中，手机验证码这些具体活动结果都被活动事件本身MI替代了。
如果你想使用DDD进行实体建模，首先要有一个聚合根，根实体，用户信息应该是这样根实体。
要区别四色建模和DDD是不一样的。
[该贴被banq于2011-10-28 07:49修改过]
例如一个注册行为，参与的role到底是什么？现在用户信息还没有诞生，或者说我们正要创建参加业务逻辑的参与者，还没创建出，何来参与呢？
注册行为，有别于管理员的新增用户，想想就清楚了。
所以注册登陆与领域逻辑无关，可以考虑放在容器上处理（即框架、平台等）。
未注册前的用户是游客(GuestUser)，游客注册成功之后成为会员(MemberUser)(还有可能是其他称呼，这里只举个例子)，游客转变为会员的这个过程就是注册。“注册”是一个场景(RegisterContext)，角色为“注册者”(RegisterUser)，扮演者为游客(Guest).
2011年10月28日 09:13 "@achilleswar"的内容
未注册前的用户是游客(GuestUser)，游客注册成功之后成为会员(MemberUser)(还有可能是其他称呼，这里只举个例子)，游客转变为会员的这个过程就是注册。“注册”是一个场景(RegisterContext)，角色为“注册者”(R ...
这个前提就是引入Guest，但注意，参与业务逻辑的不是Guest，而是Member，也就证明了，注册登陆与业务逻辑无关。
Guest--注册登陆--Member--业务逻辑（这表达关联）。
引入Guest未尝不可，但在开放式WEB应用下，可能会带来复杂，我一般只在封闭式系统下使用这个Guest概念的。其实Guest存不存在，仍是系统问题，而非业务逻辑问题。
2011年10月28日 11:47 "@SpeedVan"的内容
其实Guest存不存在，仍是系统问题，而非业务逻辑问题 ...
不明白你的意思。