这是我们的商业案例，
应用程序为使用过的iPhone提供即时报价，并允许卖家立即出售。另一方面，有买家愿意立即购买或出价上市。潜在的零售商可以访问网站并根据年份，型号，条件，配件输入获得即时报价[iQuote123]。
每当有人使用该流程时，系统都会创建新的报价ID。如果卖家决定接受报价，则会立即接受更多关于序列号，照片等的信息。系统将生成唯一的交易ID [iTransaction123]。
在极少数情况下，由于条件问题，买家可能不会出现或拒绝iPhone。我们可能会为卖家找到另一个买家。
我想征求关于我们是否应该在接受要约后如果买方更改或卖方稍后更改条件时生成新的交易ID的意见。
如果我们保持相同的交易ID，那么卖家只需要记住一个有意义的参考，因为它对于同一个iPhone而言只是不同的买家，但是对于后端支持人员，它会为这个独特的交易创建通信线程。新老买家。我认为最好的处理方法是为买方交易[iBuyerTransaction123]创建一个单独的对象，并将其与卖方的交易映射，以便在第一个买方未能执行时为同一卖方创建多个买方交易对象。
我正在寻找处理域名身份的最佳方法，其中包含何时创建身份以及何时重用身份的指南。
答案 0 :(得分：6)
我想征求关于我们是否应该在接受要约后如果买方更改或卖方稍后更改条件时生成新的交易ID的意见。
domain-driven-design中最常见的答案 - 请咨询您的域名专家。
根据您的描述，我希望您的模型中有一个您尚未发现的实体，代表买方和卖方之间建议的交换。
猜测（我不知道你的域名），你真的有两件不同的事情在这里发生。首先，您有一堆购买请求并出售您想要匹配的请求。然后，在找到匹配后，有一些交换进程，通过双方之间的实际协商。在快乐的道路上，双方都满意，一切都达到了生命的终点。当其中一方对交易所不满意时，交易结束，但双方重新回到匹配堆中。
您需要一个实体来跟踪此过程的状态。
卖家的观点将被键入其一个参考，并且该密钥将用于查找当前的交易所（如果正在进行中）以及先前已关闭的交易所（如果有的话）。
这实际上是建模中的一种常见模式 - 当您有两个实体，每个实体都有一个独立的生命周期时，这两个实体之间的交互通常在第三个实体中跟踪，该实体有自己的生命周期。