I've noticed that in large Java hierarchies, where I spend a lot of my time, people often use interfaces where they really should be using modules. Like, there'

I've noticed that in large Java hierarchies, where I spend a lot of my time, people often use interfaces where they really should be using modules. Like, there's this vague concept of a "service" and methods of this service are bound together via an interface. Which ends up coupling all kinds of weird dependencies in the class definition. My guess is that this is a similar case in Typescript that the author is describing. So, this approach is, instead of having IFooService with two methods, IFooService.doOneThing and IFooService.doAnotherThing you just have a package "fooservice" with functional interfaces DoOneThing and DoAnotherThing. This seems to still play nice with most of the tooling, and often, keeps the code simpler and makes it easier to refactor. DoOneThingImpl and DoAnotherThingImpl can easily share code, but that aspect shouldn't matter at all to the caller. Another way of thinking about it: don't worry too much about a perfect interface for layering your business logic initially. Start with just some functions, then as you spot patterns you may recognize there's a state pattern that does things better. I don't think this is really specific to Typescript.