【发布时间】:2012-12-26 17:54:24
【问题描述】:
问题上下文
所以我将我的应用程序组织到有界上下文中(Eric Evans 的“领域驱动设计”)。有界上下文之一是“游戏性上下文”。例如,它包含一个接口Gamer
public interface Gamer {
void setFriends(Set<Gamer> friends);
Set<Gamer> getFriends();
....
}
还有一个实现可以将Gamer 的状态持久化到数据库中。
@Entity
public class JpaGamer implements Gamer {
private String someData;
private String someSensitiveData;
public setFriends (Set<Gamer> friends) {
...
}
...
}
很远很远,在另一个称为“帐户上下文”的有界上下文中,我有处理我的应用程序用户的类和接口。例如,有一个名为Account 的接口。
public interface Account{
boolean isSignedUp();
....
}
所以用户 /Account 可以注册或不注册。对于任何Account,都有一个对应的Gamer。
挑战
我有一个业务规则:永远不要保留与未注册相关的敏感数据Account。
例如,这意味着某些未注册的Account 的JpaGamer 实例无法将数据写入someSensitiveData 字段。您可以非正式地说这个JpaGamer 是“未注册的JpaGamer”。
我不想将任何与帐户相关的逻辑硬编码到任何与游戏相关的内容中(反之亦然)。
我怎样才能在 Java 中实现这样的业务规则,而不用来自另一个有界上下文的概念污染任何一个有界上下文?
为了满足业务规则,我的想法是,只要有“未注册的JpaGamer”,我就将JpaGamer 包装在SparsePersistingGamer 中。 SparsePersistingJpaGamer 根本不会将任何可能篡改someSensitiveData 的方法转发给底层JpaGamer。
但是现在我遇到了someGamer.getFriends() 方法的问题。对于SparsePersistingGamer,它会懒惰地从JPA 加载所有玩家的朋友,返回一组不知道(和任何其他)业务规则的普通JpaGamers,因此坚持someSensitiveData 可能“非-注册JpaGamers"。
您采用哪些策略来处理类似和相关的情况?
【问题讨论】:
-
DDD nitpick:
Gamer真的应该直接访问Set<Gamer>的朋友,而不是Set<GamerId>的朋友吗?所有连接的Gamers 的整个友谊网络听起来太大而不能成为单个聚合根。
标签: jpa domain-driven-design business-rules bounded-contexts