Domain object identity reuse vs create new

Question

Here our business case,

Application provides instant quote for used iPhone and allows seller to sell it instantly. On other end there are buyers who are willing to buy it instantly or bid on the listings. Potential retail sellers can visit website and get instant quote[iQuote123] based on year, model, condition, accessories inputs.

System creates new quote id every time someone uses the process. If seller decides to accept the quote then it will be accepted immediately with some more info about serial no, photos etc. System will generate unique transaction id[iTransaction123].

In rare case, a buyer may not show up or rejects the iPhone due to condition issues. We may find another buyer for seller.

I want to seek opinion about if we should generate new transaction id if buyer changes or seller later on changes condition after accepting the offer.

If we keep same transaction id, it keeps things simple for sellers to remember just one reference which makes sense since its for same iPhone but just different buyer though for backend support staff, it creates communication thread for that unique transaction with communication from old and new buyers both. I feel the best way to handle is create a separate object for buyer transaction [iBuyerTransaction123] and map it with seller's transaction such that it will creates multiple buyer transaction object for same seller in case 1st buyer fails to carry out it.

I am looking for the best way to handle domain identities with guideline on when to create identity and when to reuse it.

Answer 1

I want to seek opinion about if we should generate new transaction id if buyer changes or seller later on changes condition after accepting the offer.

Most common answer in domain-driven-design -- check in with your domain experts.

Based on your description, I would expect to find that there is an entity in your model that you haven't yet discovered, something that represents the proposed exchange between a buyer and a seller.

Speculating (I don't know your domain), you really have two different things going on here. First, you have a pile of buy requests and sell requests that you are trying to match up. Then, after you have found a match, there is some exchange process that works through the actual negotiation between the two parties. In the happy path, both parties are satisfied, and everything reaches end of life. When one of the parties is unsatisfied by the exchange, then the exchange ends, but the two parties go back into the matching pile.

You need an entity to track the state of this process.

The seller's view would be keyed to their one reference, and that key would be used to look up the current exchange (if one is in progress), and previously closed exchanges (if any).

This is actually a common pattern in modeling - when you have two entities that each have an independent lifetime, the interaction between those two entities is often tracked in a third entity, which has its own life cycle.