With a Rails background the article Bring clarity to your monolith with Bounded Contexts may be more informative than any output any generator may create.

There is no code metric like “ideal number of functions per module” that defines what a good context is. The ideal boundaries have to come from your understanding of the “business problems” that your application deals with.

Contexts partition the application into distinct areas of your problem domain. Functionality within the same context shares the most detailed information in order to achieve the focused objective of that particular area (high cohesion, high coupling) - while at the same time only sharing the most essential information with other contexts to avoid them becoming dependent on details that may need to change in the future (low coupling).

If that works (and it might) then I suspect you are dealing with a (by and large) CRUD application - i.e. a situation that frankly “bounded contexts” were not meant to manage. It is always important to remember that bounded contexts don’t always apply and that there is a place for Smart UIs - the problem is that Smart UIs have a limited growth potential should the domain evolve and become more complex (which may never happen).

I would agree that in general controllers are simply part of the web UI which in effect simply renders a representation of the relevant information found in the associated context - so as such it would make sense to keep them outside of the “bounded context”. I also think that the article simply captures their own understanding of their problem domain (and DDD) at the time of writing and the article may look quite different if it was written now.

There seems to be the expectation that one should be able to get the contexts “right” on the first try. Eric Evans actually paints quite a different picture:

Often, though, continuous refactoring prepares the way for something less orderly. Each refinement of code and model gives developers a clearer view. This clarity creates the potential for a breakthrough of insights. A rush of change leads to a model that corresponds on a deeper level to the realities and priorities of the users. Versatility and explanatory power suddenly increase even as complexity evaporates.

This sort of breakthrough is not a technique; it is an event. The challenge lies in recognizing what is happening and deciding how to deal with it.

(Domain-Driven Design: Tackling Complexity in the Heart of Software p. 193)

So in the end identifying contexts is quite a “fuzzy” activity - at least from a technology perspective.

I’ve used smaller targeted service modules before trying out context approach and can confirm that contexts uniting public APIs of several such modules (like accounts) can get pretty big.

What I do is only add defdelegate calls and documentation to the context module and do the actual work in the (basically same) service modules under this context, these service modules have as much private functions as possible and only expose the required minimum.

Not sure how idiomatic this approach is, but it helps dealing with module size without resorting to unnecessary splitting and feels quite clean to me.