在DDD中,据我所知,它可以帮助或指导您如何构建复杂的应用程序.现在在应用程序中,您应该识别您的有界上下文.假设您有超过10个BC.
我在某处阅读(原谅我,我不能给出任何链接),对于复杂的应用程序来说,拥有一个大数据库是不理想的.它应该为每个BC分开.如果这是更容易的路线.如果每个BC都有自己的数据库,应如何构建应用程序.
解决方法
这取决于它们只共享相同的数据库还是一些表 – 即数据.
共享数据库而不是表可以完全没问题.除非您的目标是可伸缩性,并打算使BC的可独立部署和可运行的单元(如微服务),在这种情况下,它们应该有自己的数据存储实例.
我发现由2个或更多有界上下文共享的数据库表有一些缺点：
>紧耦合.我们有不同BC的原因是它们代表了可能以自己的方式发散的不同域空间.改变其中一个BC的概念可能会影响基础表,迫使使用该表的其他BC也发生变化.你应该在柔软的地方获得刚性.由于多种可能的更改源,您可能还会在数据中出现不一致或“漏洞”.
>并发.在高度并发的系统中,某些实体和下面的表受到强烈争用.有界上下文是通过分离不同类型的写入来减轻负载的方法之一,但只有在它们在一天结束时不锁定相同数据时才有效.对于非CQRS系统中的读取也是如此,其中它们查询完成写入的相同数据库.
> ORM友好.大多数ORM不允许您从同一个数据库表映射到2个或更多类,而没有大量的卷积和变通方法.
How should one structure an app if each BC have their own database.
在某种程度上(例如,可能包括UI层),就像您有多个单独的应用程序一样.如果您有精确的问题,请更具体.
