My last two projects have a “sign up”/“Register” part, a “landing page”/“introduction homepage” and then the actual application (usually a Dashboard/Manager of some kind).
I sometime end up with a package structure like
ProjectName.ProjectName containing all data related models.
ProjectName.Register a package taking care of the sign up process
ProjectName.Homepage a pacakge taking care of the landing page/homepage
ProjectName.Dashboard a package that is the actual application, that requires authentication and give user specific access to certain action
The idea behind it, is to keep all data and command/queries inside the ProjectName.ProjectName package and have a single entry through a CommandBus and with Command classes in the ProjectName.ProjectName package.
Inside the ProjectName.ProjectName package I have different Contexts splitted by different folder in the Classes folder.
How does such a solution look and sound to you? How do you organize projects with these different part?
It’s difficult to come up with a rule of thumb because the separation highly depends on the case of course.
But in general I’d suggest not to split the Bounded Context along technical concepts but rather on the parts that have a specific meaning (i.e. language) in the domain.
I’m looking for other Flow users experience on creating a scalable application with many different application contexts, where the visitor/user is in a different state (interested, registered, admin etc) that will lead to different interface