earlier replies
Replying to @jeppec
@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?
1
1
@stilkov @jeppec Agreed but my point is that the guarantees and tradeoffs that SAP introduce impact.
1
@kellabyte @stilkov true but that could be isolated to the ACL (eg you want to perform book keeping in SAP related to a domain event)
2
Replying to @jeppec
@jeppec If @kellabyte’s point is that to believe *everything* can be abstracted away is naïve, my guess is we can all agree.

Oct 19, 2015 · 6:08 AM UTC

3
1
Replying to @stilkov
@stilkov @jeppec Yup but a lot of material talk about each part being completely independent
Replying to @stilkov
@stilkov @jeppec And I propose that your model could completely change depending on outside guarantees or tradeoffs.
1
more replies
Replying to @stilkov
@stilkov @kellabyte indeed. What I've tried to bring across is that this is not the intention of DDD to do that either