假设我为我的客户建立了一个系统,允许赌徒保持投注组合并跟踪他们的收益/损失. 该系统支持许多复杂的域逻辑 – 对不同的体育运动下注,将胜利滚动到其他投注等. 接下来,我的客户希
该系统支持许多复杂的域逻辑 – 对不同的体育运动下注,将胜利滚动到其他投注等.
接下来,我的客户希望支持提示者的想法.提示者实际上并不赌博,而是他们
创建“提示表”,这是他们下注的提示.尖端片可以是不同的
种类 – 一些可以包括任何可下注的事件的提示,其他人只提供有关赛马的提示,等等.
我的客户希望系统跟踪提示者的性能,就像跟踪其性能一样
赌徒,还有能够比较不同类型的推特内部和之间的表现的额外扭曲(例如,谁是最好的赛马推特？他们一般表现得比足球推销员更好吗？)
现在,域名语言在赌徒和提示者之间是完全不同的,还有其他的
赌徒投资组合中不存在的提示表分类.这表明这些是独立的有界背景.
但是,有很多共享逻辑,因为它们都会跟踪性能.
所以我的问题是：
>这些是真正独立的有限背景吗？我很担心在赌徒的背景下加入分类(感觉就像一个滑坡).
>如果他们是不同的背景,我应该：
>在它们之间共享性能跟踪逻辑(即共享DLL,jar等)？这在感觉错误的上下文之间创建了紧密的实现耦合.
>将性能跟踪逻辑留在赌博有界的上下文中,将分类逻辑放在tipster bounder上下文中,让它让赌博环境跟踪性能？在这种情况下,似乎推特上下文会向赌博上下文发送命令,这再次感觉不对(我对事件更加满意).
>做其他事情……某种组合层在两种情境之间进行沟通和关联？
澄清
赌徒的投资组合和推特的提示表几乎相同 – 唯一的区别是提示表可以分类(例如赛马,足球等).
绩效跟踪是关于衡量投资组合/提示表的盈利/亏损.
我可能会同意迈克的观点,即性能跟踪本身就像是一个有界的上下文.这看起来更明显的边界.Betters和Tipsters可能会对相同有界上下文或不同有界上下文的不同聚合进行操作.根据你对语言的看法,以及项目的演变,我倾向于选择后者.