Procurements - Documents - Comments - Aggregate design in microservices

[Dimitrios Psarrou]

Hello everyone,

First I would like to thank you for this forum and sharing of knowledge.
I would like to hear your opinions on how you would design the following system in a most effective and highly available way:

An exemplified description of the system I'm currently working on:

In a SaaS solution for procurements (requests -> quotes -> order) there are Users that can send a Request and Vendors (companies) that receive and reply to those requests with a Quote.

The registered user can

• create a request and save it for later
• create a request and directly send it to the vendor
• send a previously saved request to a vendor
• update a request with more data only if its not submitted yet.
• cancel an existing active request

The vendor (which can have multiple users) can

• reject a request
• send one or more quotes in response to the request
• save a quote for later
• update the quote if it hasn't been sent yet
• cancel an existing active quote

To complicate things:

• The request has an expiry date, no further action can happen (send a quote or something) if the date is greater than the expiry date.
• The user can postpone (change) the request expiry date
• The quotation also has an expiry date and same thing as above happens, this time from the vendor side
• The request forms are custom per vendor (each vendor can have his own request form)

To further complicate things one more time:

• The request and the quote can have comments from the user and the vendor
• No comment can be added if the request has expired. Same thing for the quote.
• The quote will be ordered at one point. When it is, no further action can happen to it.
• a payment system will be introduced in the future and many more.. ^^

My current implementation and reasoning behind it is:

The user is submitting a Form (aggregate that contains the rules of the custom form) and produces an Entry (aggregate). Using this aggregate the user can update the form data and also submit it to a vendor. The submission event is caught asynchronously by a separate service that will create a Request aggregate. This way I can decouple the customer side of the application from the vendor side into 2 services, and keep the Request aggregate as a model for the vendor business functions.

 
Now my questions:

• It seems most of the aggregate events carry a "UserId" in order to track which user was involved in that event. Is there a best practice for this, as I don't really like how the aggregate is looking?
  
• How do you protect invariants? If an Entry gets updated while Request has been rejected? Or for example the comments?. Same thing for quotes. I would like to avoid having the Request aggregate contain a list of quotes or comments.
  

I think this can be greatly simplified, but I'm looking for your opinions and best practises.

Thanks in advance for the feedback!

Dimitrios

[Aryeh]

Hi Dimitrios,

Just some food for thought.  Consider me like the 10th man in the movie World War Z [*1] ...

How are you organizing your logic?  Do you have a rich domain model, or are you basing your solution on another pattern / architecture?  You seem to mention "aggregates" a lot, so is it an "aggregate-driven design" focused on transactions and eventual consistency?  The way you describe "submitting a Form (aggregate) and produces an Entry (aggregate)", makes me think it might as well be a transaction script, or a unit of computation in a functional paradigm.

I sense a focus on architectures, technologies, patterns, layers and wiring, instead of a focus on modeling your domain problem in code.

Perhaps consider that if you do create a rich domain model, without regards for persistence and UI, you could have an initial working system driven by tests that fulfilled the features (and constraints) you list, in a few days.  THEN refactor for concurrency and consistency, and layers, service boundaries and technologies, and a clearer model.  Instead of a single strategy, you can consider how each part and interaction in your model, is consistent and supports concurrency in terms of the particular business scenario.

If you want, feel free to send me an email to chat about any of this.

Best regards,
Aryeh

[1] https://www.quora.com/World-War-Z-2013-movie-Do-the-Israelis-really-have-a-10th-man-doctrine