阅读时间： 2 分钟
读取模型和写入模型......它们是什么，它们从哪里被驱动。在这篇博客中，我们将简要地讨论CQRS、读模型和写模型。
CQRS- 是什么，为什么和如何...？
到目前为止，我们已经使用了许多不同的架构、模式和实现，它们围绕着命令查询分离（CQS）的核心概念。这种原则背后的核心思想是创建针对单一目的的代码，通常没有副作用，更容易工作和维护。
这种传统架构的问题是，同一个数据模型被用来查询和更新数据库。这很简单，对于基本的CRUD操作来说效果很好。在遇到更复杂的问题时，它们就显得不那么容易了。
因此，我们引入了CQRS。CQRS是Command and Query Responsibility Segregation的缩写。它是一种推理特定领域活动的有用模式。但它肯定会有一个陡峭的学习曲线。读取、写入、DDD、事件源、最终一致性。
因此，出现的问题是，我们是否真的需要CQRS。让我们花点时间来思考一下这个问题。CQRS在几年前还不是很典型，但现在我们可以找到很多关于它的内容，很多公司都在使用它，并就它进行交流。我们可以在不知不觉中进行CQRS!
它并不意味着使用微服务，或消息基础设施，或事件，或在本质上做DDD。它只是经常与这些技术一起使用的原因。
我们什么时候应该使用CQRS模式！？
在下列情况下，我们可以使用CQRS模式。
- 在一个系统的读写数量相差很大的情况下（社交网络就是这种系统的例子），它是完美的。你可以独立地扩展双方，例如，你可以分配更多的资源给读服务。
- 如果你想并行开发并使用两个团队。一个团队可以被分配到读取模型，第二个团队分配到写入方面。然而，请注意，这两个团队都必须对CQRS模式有深刻的了解。
- 多个服务竞争改变相同的资源。
- 可能有这样的情况，一个团队的开发人员可以专注于作为写模型一部分的复杂领域模型，而另一个团队可以专注于读模型和用户界面。
一个写模型，N个读模型 -
围绕CQRS的想法是使一个应用程序（在大的意义上）能够工作在若干个模型上。
- 它只有一个，而且是唯一的一个内部模型，它是用命令来改变的。
- 可能有一个或几个它和其他应用程序的读取模型（它只是因为我们不能让其他人读取写入模型）。
虽然，即使读模型可以被前端或API读取，这也不重要。
结论 --
在这篇博客中，我们已经了解了所有关于传统的架构和原则。然后，我们讨论了CQRS来克服传统模型所面临的问题。读取模型与写入模型，如何使用以及为什么我们使用它。
