blocks|key|2593325|text|解决这一问题的正确的DDD/微服务方法是什么？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|2593326|一般的答案是，你让时间成为你的定价模型的一个明确的部分。对产品目录进行的价格更改有一个生效日期，这意味着您可以通过对订单中的时间进行建模，就购物者在订单时看到的价格达成完全一致。|unstyled|2593327|这可能会引入QuotedPrice作为独立于目录价格的东西的概念，在目录价格中，报价承诺在一定时间内保持价格。|2593328|为了全面解决这类问题，以下是三份重要的文件供检讨：|2593329|回忆，猜测和道歉--+Pat+Helland，2007年|unordered-list-item|offset|length|2593330|外部数据与内部数据--+Pat+Helland，2005年|2593331|种族条件不存在--+Udi+Dahan，2010年|2593332|entityMap|0|LINK|mutability|MUTABLE|url|https://web.archive.org/web/20100722052618/http://blogs.msdn.com/b/pathelland/archive/2007/05/15/memories-guesses-and-apologies.aspx|1|https://blog.acolyer.org/2016/09/13/data-on-the-outside-versus-data-on-the-inside/|2|https://udidahan.com/2010/08/31/race-conditions-dont-exist/^0|0|0|0|0|B|H|0|0|C|H|1|0|A|F|2|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|14|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|15|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|16|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|17|8|@]|9|@$L|18|M|19|1|1A]]|A|$]]|$1|N|3|O|5|K|7|1B|8|@]|9|@$L|1C|M|1D|1|1E]]|A|$]]|$1|P|3|Q|5|K|7|1F|8|@]|9|@$L|1G|M|1H|1|1I]]|A|$]]|$1|R|3|-4|5|D|7|1J|8|@]|9|@]|A|$]]]|S|$T|$5|U|V|W|A|$X|Y]]|Z|$5|U|V|W|A|$X|10]]|11|$5|U|V|W|A|$X|12]]]]

<blockquote>
What is the proper DDD/microservices way of solving this?
</blockquote>
The general answer is that you make time an explicit part of your pricing model. Price changes made to the product catalog have an effective date, which means that you can, by modeling time in the order, have complete agreement on what price the shopper saw at the time of the order.
This might introduce the concept of a QuotedPrice as something separate from the Catalog price, where the quote is a promise to hold a price for some amount of time.
To address this sort of problem in general, here are three important papers to review:
<ul>
<li>Memories, Guesses, and Apologies -- <a href="https://web.archive.org/web/20100722052618/http://blogs.msdn.com/b/pathelland/archive/2007/05/15/memories-guesses-and-apologies.aspx" rel="nofollow noreferrer">Pat Helland, 2007</a></li>
<li>Data on the Outside vs Data on the Inside -- <a href="https://blog.acolyer.org/2016/09/13/data-on-the-outside-versus-data-on-the-inside/" rel="nofollow noreferrer">Pat Helland, 2005</a></li>
<li>Race Conditions Don't Exist -- <a href="https://udidahan.com/2010/08/31/race-conditions-dont-exist/" rel="nofollow noreferrer">Udi Dahan, 2010</a></li>
</ul>

blocks|key|2166920|text|我认为解决这一问题的方法之一就是事件。正如您所说的，Product和Order可以是最不独立的聚合，我会保持它们松散耦合。将它们放在一个单一的总根中将违背开放/封闭和单一责任原则。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2166921|如果Product更改，它可以引发一个ProductChanged事件，也可以引发一个Order事件。|2166922|根据这些域对象是在同一个服务中还是在不同的服务中，您可以创建域事件或集成事件。阅读更多关于它的这里。|2166923|从上述链接：|2166924|域事件是您希望同一域(进程中)的其他部分注意到的域中发生的事情。通知的部分通常会对事件做出某种反应。|blockquote|2166925|我认为这完全符合你的情况。|2166926|entityMap|0|LINK|mutability|MUTABLE|url|https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation^0|Q|7|Y|5|0|2|7|J|E|17|5|0|1B|2|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|13|8|@$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1A|8|@]|D|@$9|1B|A|1C|1|1D]]|E|$]]|$1|J|3|K|5|6|7|1E|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|1F|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|1G|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|1H|8|@]|D|@]|E|$]]]|R|$S|$5|T|U|V|E|$W|X]]]]

I think one way to solve this through is Events. As you said, <code>Product</code> and <code>Order</code> can are very least separate aggregates, I would keep them loosely coupled. Putting them into one single aggregate root would against Open/Close and Single Responsibility Principle.
If a <code>Product</code> changes it can raise a <code>ProductChanged</code> event and likewise of an <code>Order</code>.
Depending on whether these Domain-Objects are within the same service or different service you can create a Domain-Event or an Integration event. Read more about it <a href="https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation" rel="nofollow noreferrer">here</a>.
From the above link:
<blockquote>
A domain event is, something that happened in the domain that you want other parts of the same domain (in-process) to be aware of. The notified parts usually react somehow to the events.
</blockquote>
I think this fits perfectly to your scenario.

What is the DDD way of handling the following scenario:
<ol>
<li>user enters <code>Order Create</code> screen and starts creatingnew <code>Order</code> with <code>OrderItems</code></li>
<li>user chooses <code>ProductX</code> from products catalog and adds quantity</li>
<li><code>OrderItem</code> for <code>ProductX</code> is created on <code>Order</code> and user goes on adding another product</li>
<li>in the meantime, before <code>Order</code> is saved, admin changes price for ProductX</li>
</ol>
Assuming <code>Product</code> and <code>Order</code>/<code>OrderItem</code> are separate aggregates, potentially even separate bounded contexts, how is this handled?
I can think of several options:
<ol>
<li>optimistic concurrency combined with db transactions, but then if we broaden the question to microservices where each microservice has its own db - what then?
</li>
<li>joining everything into one giant AR but that doesn’t seem right.
</li>
<li>introduce a business rule that no product prices are updated during the point of sales working hours but that is often not possible (time triggered discounts, e.g.)
</li>
</ol>
What is the proper DDD/microservices way of solving this?

Product price changed while creating order

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

DDD处理以下场景的方法是什么：用户进入Order Create屏幕并开始使用OrderItems创建新的Order用户从产品目录中选择ProductX并添加数量OrderItem for ProductX是在Order上创建的，用户继续添加另一个产品同时，在保存Order之前，管理员会更改ProductX的价格。假设...

问定单时产品价格发生变化
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问定单时产品价格发生变化EN