.net - 域驱动的设计:微服务(CQRS + ES)，客户端可见性和元数据

Question

如果我提出的问题或陈述不正确，请原谅我，我是微服务开发中的新手。我正在研究更改与我的业务相关的商业软件。现在，这与我近年来编写的当前软件所达到的极限有联系。

DEV CONTEXT :

我在许多欧洲国家/地区出售本地食品。我有2家实体店，其中1家是与ebay和Amazon商店“相连”的公司在线购物。我这些年编写的程序是 Web解决方案(SQL DB上带有EF6的.NET MVC / API)，由 2 Web应用程序.NET / AngujarJS (公共CLIENT +私有ADMIN)和各种C#库组成:数据访问，数据模型和共享实用程序。一切都由该软件集中管理。

建筑限制:

该项目引起了对新体系结构的需求，以打开新的物理商店并引入移动应用程序。用单一的读写源来管理一切(我尝试在所有地方使用缓存Redis)现在变得太局限，缓慢且昂贵。正如以“敏捷”方式扩展具有新功能的软件的限制一样。因此，我正在研究完全重写基于微服务的软件。

带有微服务的新架构:

我脑海中浮现的结构:

带有REST API的

微服务“主干”事件存储(用于保存事件)
和Subscription API(用于订阅的ON / OFF事件)。 (Azure SQL
数据库+后台检查过程+ Azure服务总线)

许多具有DDD + CQRS / ES的微服务(.net核心API-CosmosDB和MongoDB)

一些带有简单CRUD的微服务(.net Core API-SQL DB)

APP使用服务

我的个性:

从以 数据中心模式(EF数据模型+ CRUD op)来思考软件到捕获 “行为” (DDD模型+ ES / CQRS)的软件的转变无疑是开始此过程中最令人兴奋和困难的部分路径。在以下情况下，我对如何采取行动感到困惑:

设置数据可见性(管理端)以显示客户端

在特定聚合上设置客户端设置(例如，打开/关闭评论-打开/关闭评论)

设置与域无关但与客户端需求(例如SEO元描述)相关的数据

让我们以出售产品为例。在将其显示给客户之前，必须输入并检查所有数据。
过去，我在数据库数据模型中插入了一些简单的布尔值ON_OFF_Visibility，然后修改布尔值 的ADMIN端就足够了，因此 的CLIENT端可以看到或看不到产品。现在使用 DDD方法，用类似数据弄脏聚合模型是不正确的。因此，我想采取以下行动:

将ON / OFF发布仅视为PublishProduct(WRITE
SIDE)命令。

然后生成产品发布的事件(保存并发布在总线上)

READ SIDE接收事件并更新实例化视图。

换句话说，视图模型已更新，在管理员方请求后，该产品变为可见。



这是正确的行为方式吗？ 是否想要简单地捕获用户的行为，将其保存为事件并更改与视图模型相关的数据是否正确？对与SEO元描述和元数据有关的数据(仅影响客户端并且与业务模型无关)进行相同的推理，是否可以认为是正确的？

谢谢你的时间。

Answer 1

您的基本草图是正确的。

发送到读取端的查询是通过从缓存(图形中的mongo db实例)中获取最新的可用表示形式进行管理的，并根据该表示形式计算查询的正确答案。

通过后台进程更新缓存，该后台进程将事件转换为存储在缓存中的表示形式。

通过向位于写端的域模型发送消息，将新事件添加到系统中。写操作本身通常是同步的，也就是说，在处理消息时，通常只有在获得确认该消息产生的事件已成功存储的确认后，您才通常会发出信号来表示消息已完成/已处理。