How to structure sign up from actual application


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?

Hi Søren,

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.

If we look away from the data stuff and bounded context and simply look at the functionality - how would you do then?

What is the problem you’re trying to resolve here, as in: Why do you want to split it up to begin with?

  • make the packages easier to reuse in other projects?
  • make the packages easier to maintain?
  • make it easier to work on the project with multiple people/teams?
  • scalability?

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