No, its really not. If your notion of how to model an application begins and ends with the surface area provided by Phoenix (or Rails for that matter) then I’d urge you to dig quite a bit deeper, because you’ve got a long way to go.
Phoenix is a mediator between the interface (HTTP/websockets) and your application. It gives you a place to move data from one boundary to another. You can cram code into that seam all you want in the name of simplicity, but don’t act like nobody ever told you it was a bad idea.
Yes, there’s no middle ground between modularity-via-application and the framework-bound monolith.
I’m not altogether wild about the generator changes, but in fairness to the team, I haven’t used them much either—I just create my modules as I need them. I’m not really sure how you hold up a Rails-style application structure as the way to go on one hand, then point to DDD with the other. I think the terminology used in Chris’s keynote comes pretty well loaded and there’s a lot of people coming into Elixir and Phoenix with some degree of confusion wondering if they need to bite off the absolutely massive mental undertaking that is understanding DDD and how to apply it, and that’s unfortunate. Because the essential point is absolutely sound: Modularity is more than just a namespace or code geography, and there’s more tools to achieve it than a completely separate application.
