我将 DDD 用于面向服务的应用程序，旨在在大量网络客户端（即浏览器）之间传输大量消息。
因为在所需功能的情况下，传输需求大于存储需求，我喜欢主要依赖 RAM 并尽量减少数据库使用的想法。
但是，我不清楚如何从可扩展性的角度构建它。 Web 场创建服务端点和域逻辑处理的高可用性。但无论我有多少台服务器，似乎它们都必须共享一个公共存储库，以便它们的数据保持一致。
如何构建此存储库以使其尽可能具有可扩展性？如何以一种方式将它分散到一组物理机器上，使所有机器都保持一致，并且如果另一台机器出现故障，每台机器都不会在意？
此外，由于偶尔需要接触数据库（例如，当客户端丢失并且必须存储发送给它的消息直到它返回时），我应该如何组织基于内存的代码和数据访问层？它们都被视为“存储库”吗？
【问题讨论】：
标签： domain-driven-design repository scalability soa volume
有几种方法可以解决这个问题。没有一个答案可以真正涵盖所有内容...
确保您的可扩展性的一种方法是简单地扩展硬件。将您的 Web 服务编写为无状态的，以便您可以运行一个 Web 场（都运行相同的相同服务，指向同一个数据库）并将您的数据库变成一个集群。集群数据库在多台服务器上运行并在同一个存储上工作。但是，这种情况很快就会变得复杂且昂贵。
一些有趣的链接：
另一种方法是看架构。 CQRS 是一种确保可扩展性的通用架构模型。例如，这种架构模型——它的名字代表命令/查询职责分离——构建不同的数据库用于读取和写入。这似乎是矛盾的，但如果你研究它，它就会变得很自然，你会想为什么你以前从未想过它。简而言之，大多数应用程序的读取比写入要多得多，而写入往往比读取复杂得多（需要业务规则验证等），那么为什么不将两者分开呢？您可以使用昂贵的事务数据库进行写入，然后使用廉价的、可能基于非 SQL 或开源的数据库在多个读取服务器上进行。然后，您的读取模型针对应用程序的屏幕进行了优化，而写入模型仅针对写入进行了优化，实际上是一组基于 DDD 的存储库。
这里没有足够的空间来详细介绍此选项，但是一旦您拥有 CQRS 框架，CQRS 是实现可扩展性甚至易于开发的好方法。 CQRS 还有许多其他优点，例如易于审计（如果将其与基于 CQRS 的环境中常见的“事件溯源”技术相结合）。
一些有趣的链接：
【讨论】：
你准备好阅读了吗？有很多选择，但我相信你应该从了解现代分布式 NoSQL 数据库的优势开始，并享受在 facebook、linkedin 和其他朋友的经验中学习的乐趣。从这里开始：
【讨论】：