5 ms·
Hmm let's see we're going to - Reimplement SQLAlchemy models (we'll call it a "repository") - Reimplement SQLAlchemy sessions ("unit of work") - Add a "servi
by throw1222212121 1y ago
Hmm let's see we're going to
- Reimplement SQLAlchemy models (we'll call it a "repository")
- Reimplement SQLAlchemy sessions ("unit of work")
- Add a "service layer" that doesn't even use the models -- we unroll all the model attributes into separate function parameters because that's less coupled somehow
- Scatter everything across a message bus to remove any hope of debugging it
- AND THIS IS JUST FOR WRITES!
- For reads, we have a separate fucking denormalized table that we query using raw SQL. (Seriously, see Chapter 12)
Hey, let's see how much traffic MADE.com serves. 500k total visits from desktop + mobile last month works out to... 12 views per MINUTE.
Gee, I wish my job was cushy enough that I could spend all day writing about "DDD" with my thumb up my ass.
- florbo 1y agoI've made it through about 75% of the book and have never gotten the sense that they think everything discussed in the book is something you should always do. Each pattern discussed has a summary of pros and cons. While they may be a bit lacking, they clearly articulate the fact that you should be thinking whether or not the pattern matches the application's needs. I don't think there's many applications that will require everything in the book but there are certaintly many applications that could apply one or more patterns discussed.
- theoreticalmal 1y agoYikes
- globular-toast 1y agoOK so show us how to write software for a complex business properly. Oh, I see, it's a throwaway account. This is just drive-by negativity with zero value.