earlier replies
Replying to @kellabyte
@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 @kellabyte I agree – my reading is it advocates separation of concerns from a modeling perspective. Uncle Bob’s take is different.
2
@stilkov @jeppec anti corruption layer: “insulating the domain layer from knowing the existence of the other system.”
1
1
@kellabyte @stilkov yes - it's for integrating with another system. I.e. Not something you use internally to abstract away the db
5
@jeppec @stilkov Can the anti-corruption layer translate and adapt for the mismatch in guarantees? No it cannot.
1
1
@kellabyte @stilkov of course it cannot, thats also not what the pattern says. I feel like you WANT to misread the intentions?
2
@jeppec @stilkov “insulating the domain layer from knowing the existence of the other system.”
1
@kellabyte @jeppec It’s a very common thing, e.g. when you build an adapter to various different external accounting systems.
3
@kellabyte @jeppec In that case, you don’t want to introduce, say, an SAP dependency into your core domain layer. Surely reasonable?

Oct 19, 2015 · 6:04 AM UTC

1
1
Replying to @stilkov
@stilkov @jeppec Agreed but my point is that the guarantees and tradeoffs that SAP introduce impact.
1
more replies