The DDD concept that you pick the DB last & that the DB doesn’t matter is like saying you pick the data structures last & they don’t matter.
21
48
59
@kellabyte I agree, even though I’m not really sure DDD advocates that. Also, true for most other tech decisions, too.
1
1
@stilkov Wasn’t there an entire chapter about abstracting away technical details and strategic design?
1
@kellabyte @stilkov that's not how I've read it. It says that the model is more important. Learn it first and pick the db later
4
1
3
@jeppec @stilkov So you can’t really just slap a DB on after.
2
1
@kellabyte @stilkov true, but that learning comes from focusing on the domain.
2
@jeppec @stilkov So concurrency, isolation and various other guarantees are front and centre in ALL computer programs.
2
2
@kellabyte @stilkov we don't disagree. What DDD says learn the domain and from that pick the design/db that comes from this learning
2
@jeppec @stilkov But there may not be a DB that fits the bill and you may need to alter business behaviour to match.
2
. @kellabyte @jeppec @stilkov Are you saying that changing the DB means not only rewriting the app but also changing the business behaviour?
1
Replying to @mdpopescu
@mdpopescu @kellabyte @jeppec I would argue that depending on the exact circumstances (and DB), the answer can be a resounding “yes”

Oct 19, 2015 · 12:41 PM UTC

1
Replying to @stilkov
. @stilkov @kellabyte @jeppec Ouch. Painful. (I wasn't arguing against it, just asking for clarification.)