我将 DDD 用于面向服务的应用程序，旨在在大量 Web 客户端（即浏览器）之间传输大量消息。
因为在所需功能的情况下，传输的需求超过了存储的需求，所以我喜欢主要依赖 RAM 并最大限度地减少数据库使用的想法。
然而，我不清楚如何从可扩展性的角度来构建它。 Web 场创建服务端点和域逻辑处理的高可用性。但无论我有多少台服务器，它们似乎都必须共享一个公共存储库，以便它们的数据保持一致。
如何构建此存储库以使其尽可能可扩展？它如何以一种方式分布在一系列物理机器上，使得所有机器都是一致的，并且每台机器都不在乎另一台机器出现故障？
此外，由于偶尔需要接触数据库（例如，当客户端丢失并且必须存储为其发送的消息直到它返回时），我应该如何组织基于内存的代码和数据访问层？它们都被视为“存储库”吗？
I'm using DDD for a service-oriented application intended to transmit a high volume of messages between a high volume of web clients (i.e., browsers).
Because in the context of required functionality, the need for transmission outweighs the need for storage, I love the idea of relying on RAM primarily and minimizing use of the database.
However I'm unclear on how to architect this from a scalability point of view. A web farm creates high availability of service endpoints and domain logic processing. But no matter how many servers I have, it seems they must all share a common repository so that their data is consistent.
How do I build this repository so that it's as scalable as possible? How can it be splashed across an array of physical machines in a manner such that all machines are consistent and each couldn't care less if another goes down?
Also since touching the database will be required occasionally (e.g., when a client goes missing and messages intended for it must be stored until it returns), how should I organize my memory-based code and data access layer? Are they both considered "the repository"?
发布评论
评论（2）
有几种方法可以解决这个问题。没有一个答案可以真正涵盖所有内容...
确保可扩展性的一种方法是简单地扩展硬件。将您的 Web 服务编写为无状态，以便您可以运行一个 Web 场（所有服务都运行相同的相同服务，指向相同的数据库）并将您的数据库转变为集群。集群数据库在多个服务器上运行并在同一存储上工作。然而，这种情况很快就会变得复杂且昂贵。
一些有趣的链接：
另一种方法是查看架构。 CQRS 是一种确保可扩展性的通用架构模型。例如，这个架构模型——它的名字代表命令/查询责任分离——构建不同的数据库用于读取和写入。这看起来很矛盾，但是如果你研究它，它就会变得很自然，你会想知道为什么你以前从未想过它。简而言之，大多数应用程序执行的读取操作比写入操作多得多，而写入操作往往比读取复杂得多（需要业务规则验证等），那么为什么不将两者分开呢？您可以使用昂贵的事务数据库进行写入，然后使用廉价的（可能是基于非 SQL 的或开源的）数据库在多个读取服务器上进行写入。然后，您的读取模型将针对应用程序的屏幕进行优化，而写入模型则仅针对写入进行优化，并且实际上是一组基于 DDD 的存储库。
这里没有足够的空间来详细介绍此选项，但一旦您拥有了 CQRS 框架，CQRS 就是实现可扩展性甚至简化开发的好方法。 CQRS 还有许多其他优点，例如易于审核（如果将其与“事件溯源”技术结合起来，这在基于 CQRS 的环境中很常见）。
一些有趣的链接：
There are several ways to solve this issue. No single answer can really cover it all...
One method to ensure your scalability is to simply scale the hardware. Write your web services to be stateless so that you can run a web farm (all running the same identical services, pointing to the same DB) and turn your DB into a cluster. Clustered databases run over multiple servers and work on the same storage. However, this scenario can get complicated and expensive quite quickly.
Some interesting links:
Another method is to look at architecture. CQRS is a common architectural model that ensures scalability. For instance, this architecture model -- its name stands for Command/Query Responsibility Segregation -- builds different databases for reading and writing. This seems contradictory, but if you study it, it becomes natural and you wonder why you've never thought of it before. Simply put, most apps do a lot more reading than writing, and writing tends to be a lot more complicated than reading (requiring business rule validation etc.), so why not separate the two? You can use your expensive transactional database for writing and then your cheap, maybe Non-SQL based or open source, database over multiple reading servers. Your read model is then optimized for the screens of your application(s), whereas the write model is optimized solely for writing and is in fact a DDD-based set of repositories.
There's just not enough room here to cover this option in detail, but CQRS is a good way of achieving scalability and even ease of development, once you have a CQRS framework in place. There are many other advantages to CQRS, such as ease of auditing (if you combine it with the "event sourcing" technique, which is common in CQRS-based environments).
Some interesting links:
你准备好读书了吗？有很多选择，但我相信你应该从了解现代分布式NoSQL数据库的优点开始，并享受从facebook、linkedin和其他朋友学到的经验。从这里开始：
Are you ready for some reading? There are a lot of options, but I believe you should start by learning about the advantages of modern distributed NoSQL dbs, and enjoy learning from the experience learned in facebook, linkedin and other friends. Start here: