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?

This is the place that James and I always came back to throughout this book. “Let’s see how far we can get without persistence.”

We found that thinking about the solution in these terms shaped the way we thought about the problem.

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’ll make a few general comments:

• If a traditional CRUD design is meeting your needs, it doesn’t sound like you have any problems that need solving
• However, I don’t think of users—the most likely “god object” in any system—as simple
• And I suspect you can learn something by trying experiments where you add persistence as you would any other feature (because I definitely have every time I’ve done so)

But yeah, don’t overthink it. If you don’t have a problem, there’s no reason to change your design. (Except to run experiments to learn new things!)

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.