DISQUS

Scott P · 3 years ago

Interesting article -- okay, I'll bite. First let me say that I agree, up-front analysis is always partly wrong. Responsibilities and interfaces will eventually change. Anyone who's ever created an API or shared component lives in that world.

But, assuming a component has callers outside of a single application, how can you avoid defining a contractual interface? If components didn't have responsbilities and defined interfaces, developers calling those components would have to understand the internals of every single one of them. In a large system, that's just not realistic.

Sure it can be taken to an extreme, but what's your alternative?

Johannes Brodwall · 3 years ago

Good question, Scott.

If you are going to be used by an external application, sooner or later you will have to publish a contractual interface. However, I find that most developers break up their systems into too many applications with external interfaces before this is necessary. As long as you have a well-defined group, it's no problem to have 20 or more people using continuous integration to stay agile for a long time.

I guess my point is that: Yes, if you need to communicate with an external application, you need a contractual interface. But my experience is people overestimate the need to communicate with the rest of the world. (This is of course an observation from in-house development, I expect shrink wrap to follow different rules)