Software engineers sometimes spend too much time agonizing over whether they’ve broken any written or unwritten rules. This comes up frequently in settings like code reviews where a reviewer might comment, “This isn’t DRY (don’t repeat yourself). Let’s extract this code as a function and share it with this other place in the code base”. It’s a perfectly valid piece of feedback and often beneficial. But it also discounts that the code author may have deliberately not made the code DRY because the other place in the code base will soon have diverging requirements, and diverging requirements in DRY code sometimes means complex conditionals. The reviewer didn’t want to be the one to sign off on code that broke the DRY rule, but perhaps they should have. It would have been better to ask the author whether the code should by DRYed up.
While asking whether CDC breaks encapsulation is a perfectly valid question and likely worth asking. It’s equally important to ask whether the answer to the question changes anything for you. Assume CDC breaks encapsulation. If breaking encapsulation solves ten other difficult problems, do the benefits outweigh your costs? If so, I say break encapsulation.
It's an interesting point, and I somewhat touch on it in the article by discussing cases where exposing your persistent data model as-is are fine (and I'm sure there are more cases like that which I didn't discuss).
2 comments
[ 0.17 ms ] story [ 19.2 ms ] threadWhile asking whether CDC breaks encapsulation is a perfectly valid question and likely worth asking. It’s equally important to ask whether the answer to the question changes anything for you. Assume CDC breaks encapsulation. If breaking encapsulation solves ten other difficult problems, do the benefits outweigh your costs? If so, I say break encapsulation.
From https://lobste.rs/s/yepcsr/change_data_capture_breaks#c_hbti...