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 @kellabyte And very often, the boundary between “technical” and “business” aspects is not clear at all, or even non-existent

Oct 19, 2015 · 6:09 AM UTC

3
1
Replying to @stilkov
@stilkov @jeppec Yes, I absolutely agree that it is non-existent. I’ve never quite liked how some people define non-functional req
1
more replies
Replying to @stilkov
@stilkov @jeppec Because often technical details get pushed into non-functional req which affect function so uh?
1
Replying to @stilkov
@stilkov @jeppec How a read-committed database serves lowered guarantees absolutely affects the function of the system * UI
2
1
1
more replies