0

Given a ReceiptValidator interface and a GoogleReceiptValidator implementation that returns several data, where should I put a ReceiptValidatorResult?

Since it's related to ReceiptValidator, it could be placed in the Domain Layer.

But, what if another AppleReceiptValidator has different data? Should ReceiptValidatorResult be an interface as well?

jerkan
  • 560
  • 2
  • 10
  • 25

1 Answers1

4

It depends on your "domain" and how receipts are used. Generally speaking, if you have a service that sits on the boundary of your application like I assume the GoogleReceiptValidator does, you want it to return something that's meaningful to your domain like a "Receipt" object as an example. If it's a domain service (not sitting at the boundary) you still want to return something that makes sense to your domain like "ValidReceipt" for example or "InvalidReceipt" if it's invalid.

If another receipt validator has different data, you have to ask yourself whether you care about the data or not. If you don't care about the data but just the validity of it, then you can get away with returning same as above (validReceipt or InvalidReceipt). If you do care about the data, you have to extract what you care about maybe through a factory and return an object that makes sense to your domain.

I think the bottom line of my response is that the implementation detail of whether it's an AppleReceipt or a GoogleReceipt is far less important than what your domain needs. That is, once you get your information in the domain, if done properly, you shouldn't care whether it's an applereceipt or a googlereceipt.

Louis
  • 937
  • 8
  • 15
  • This is the correct modeling approach The result has to be meaningful and related to the domain, independent of the actual external service or infrastructure that returned it in a particular workflow. – Subhash Jul 22 '19 at 16:17