在我们当前的系统中,我们将过去单个整体应用程序中的多个服务切换为独立服务。
我们在分析方面有一个非常标准的架构(类似于lambda):
由于使用者和报告服务使用相同的表,我们打破了有界上下文,我们在这里遵循反模式,因为每次我们需要进行模式更改时,我们需要部署使用者(服务)创建数据)和报告(读取数据的服务)在“同一时间”。然后我们可能也必须部署策展服务。
我能够提出遵循有界上下文规则的唯一方法是在报表服务上公开一种方法,以根据使用者调用参数构建汇总。对于策展服务也是如此,在报告服务中公开了策展方法。在某种上帝服务中改变这种“报告服务”。
此解决方案的一个巨大缺点是,无法预测报告的延迟,因为同一个框可能正在执行批处理作业,创建大量的汇总和计算报告,因为该服务将承担多重责任。 / p>
有没有办法将这三种服务(消费者,报告,策展)设计为松散耦合,而不是直接依赖于它们之间的数据库集成?