Architecting an ecommerce application following Designing Elixir System with OTP

I feel like e-commerce makes for a great example of what we were describing in the book, because common ways to build the models can easily become problematic.

Can you still show accurate historical orders when a product is removed or goes up in price? Find data structures that can represent change over time and you’ll be in a much better place.

First off I want to thank Bruce and you for writing the book!

Can you still show accurate historical orders when a product is removed or goes up in price?

This is what I am having trouble understanding, because the data structure would be an ecto struct. As a result, all the changes will take place within a controller and a new state will get saved to the DB. For example, the admin changes the price for product A. The controller, will make an updated to product A and save it to the DB.

My question is, how do we work with DB as the structure and still capture the set of transaction?

For me, it often helps to put the database aside for a moment and figure out what data structures I really need. Once I have that, then I can ask myself how I would save it to a database.

Does that help get the ideas flowing?

As @JEG2 mentions you need to figure out what data structures you need in your application (maybe you don’t know them all at first hand, but will arise according to your needs). Its ok if your DB struct differs from your transactions.

I’m not following the book but until very recently I have been looking into “event driven design” and this talk about the commanded library plus following the github guide helped me a lot into better understanding this mental model.

Note: You don’t need to fully buy into commanded’s mental model; you can discern your system’s primitives without it, but I hope it can give you another angle to view your problem from.

This make sense! And that’s exactly what I did during my data discovery process. However, I’m unclear about the user data structure. The question that I’m trying to answer is, what type of transactions do I need to record for a user data or is this even necessary?

I also noticed that in the book user data wasn’t captured. Was it left out because its data wasn’t significant for the quiz application?

@chouzar thank you for mentioning CQRS/ES. After having read this article and watching a couple of conference talks, I believe I am able to answer my question

what type of transactions do I need to record for a user data or is this even necessary?

For the content management aspect of the ecommerce application, I don’t need to record any events for user data, a simple CRUD is sufficient enough.

We didn’t include users because the example is already complex enough and everyone shows users. We figured readers could tie that into their own designs.

I agree that simple CRUD is probably fine for your user models. I think the real trick is in getting products right.

I agree, I was also thinking of using CRUD for products as well. Since, features like

isn’t required for my application.

Thanks for sharing the article! One of the things that really worries me into going all in into a cqrs design is the feeling feeling that I have to get my entities “right” the first time.

A change that affects one of my “immutable” stores sounds like maintanability hell. Althought you could have a case that its easier to progressivelly enhance your architecture

I had the exact thought as well. I don’t want to introduce complexity until it’s really necessary.