Hacker News new | ask | show | jobs
by HumanDrivenDev 3154 days ago
I think I've come to a different conclusion reading your run down of this. The key paragraph is this:

The problem was that over time, there modules started drifting. Their domains became different ever so slightly and the owners of those modules became different teams. Now if you wanted to modify the domain object, you had to check it wouldn't break code the other teams were developing.

Isn't the real issue here that the architecture didn't keep pace with reality? It sounds like the dev who made the package had the right ideal. The real issue was subsequent devs introducing their domain specific stuff into a common package, instead of extending it or composing it with their own domain specific code.

1 comments

The point of the article is that separating the common code into two different pieces is often better than "extending or composing" the shared code. Merging code together is fine if you're willing to separate it again, but lots of devs aren't.