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.
