Wishlisting products domain constraints

[telemetrik]

Hello,

In my project we want to slowly move from monolith app to microservices. We want to start with pretty simple, wishlist microservice that will be responsible of wishlisting products for future purchases. One of the domain constraints is that you cannot wishlist a product that you already own.

Couple of choices I see here how we can solve it:

1) Wishlist microservice calls user library service for product owning information and declines request if user has product that he's trying to wishlist

2) Wishlist microservice contains its own product owning information (let's say own table independed of user library service propagated by event bus listeners) and uses it to determine invariant

3) Wishlist microservice does not check constraint at all, leaves that responsibility for front application to filter out those products.

Second one seems most clean approach, but it requires a lot of changes in current application and we can't afford it, so I prefer baby steps. What do you think?

[Jack Repenning]

On Sep 18, 2015, at 3:14 AM, telemetrik <kacala...@gmail.com> wrote:
>
> 1) Wishlist microservice calls user library service for product owning information and declines request if user has product that he's trying to wishlist
> 2) Wishlist microservice contains its own product owning information (let's say own table independed of user library service propagated by event bus listeners) and uses it to determine invariant
> 3) Wishlist microservice does not check constraint at all, leaves that responsibility for front application to filter out those products.

I think you might be starting in the wrong place.

Your system consists of at least three components: the purchase subsystem, the wishlist subsystem, and a record of what the user already owns (this may be what you call the "library service"?). Correct behavior of the wishlist subsystem depends on knowing the information owned by the library. But also, an important behavior of the purchase subsystem is notifying the library of new purchases. A purchase may happen at any time, affecting the library's catalog. The wishlist needs to respect this new purchase just as it does older ones. So, if wishlist begins maintaining its own information on what the user already owns, the wishlist code might be "cleaner," but some other code needs to get "dirtier" in order to update both the existing library and the new wishlist-library.

Refactoring the wishlist first is pulling a middle layer out of the sandwich. This, I know all about: I don't like the tasteless fake tomatoes you get in a mass-produced sandwich, so I'm all the time pulling them out of the middle. Sometimes, this works; sometimes I end up with lettuce in my lap. It's usually neater to start with the outer layers.

In your system, the library appears to be a bottom-tier common service, storing information of interest to multiple parties. Refactoring this out, so there's only one accumulator of this info, and all consumers of this info get it from there, would open the library-service up to the wishlist, and also to other potential new uses: safety recalls, co-advertising, product-centric communities; lots of potential.

--
Jack Repenning
Repenni...@gmail.com

[Kijana Woodard]

I mostly agree with Jack.

I don't think wishlist needs to "live query" the library to ensure consistency. That's a lost cause anyway because a purchase might get recorded 1ms after the query.

I assume the wishlist updates itself when something is added to the library.

Wishlist can maintain a list of owned product identifiers. As Product Added events are emitted from the library, the wishlist can update itself ("Congratulations on getting xyz!"). Thus even if the wishlist is slightly behind the library [stale data], it will get corrected.

This allows wishlist to be autonomous with respect to user requests.

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Andrew B]

For option (1) your wishlist microservice might produce and consume APIs like these:

Produces:

POST /user/{user}/WishListProducts/{product}

For other apps (maybe wishlist UI) to add wishlist items

GET  /user/{}/wishlistProducts

For other apps to see a user's wishlist

POST /users/{}/purchases/{product}/pings

For wishlist app to listen for new user purchases i.e. library (so it can remove products from wishlist)

Consumes:

GET /users/{user}/purchases

So wishlist can see if user has already purchased a product (so as to approve/disapprove adding wishlist product)