How do you break down the User Interface layer (MVC) so that multiple teams can work on it?

Question

I am trying to break down a large application so that multiple teams can work on it. I have created a number of Bounded Contexts for the domain layer. Each bounded context is contained in its own solution with an Infrastructure layer and a Service Layer. There is one repository per aggregate root.

How do you deal with the User Interface layer? Please see this article here: http://arunendapally.com/post/how-to-use-a-mvc-area-in-multiple-applications. Say I have three bounded contexts. Is it normal to split the UI into three MVC areas. Each area would represent a bounded context. Therefore the team developing bounded context 1 would also develop Area 1. Is it normal to do this:

1) Team 1 develop Area 1, which references the main MVC5 app

2) Team 2 develop Area 2, which references the main MVC5 app

3) Team 3 develop Area 3, which references the main MVC5 app

Is it normal to map Areas to Bounded Contexts like this? If the answer is no, then how do you break down the User Interface layer (MVC) so that multiple teams can work on it?

Answer 1

Is it normal to map Areas to Bounded Contexts like this?

Common sense typically would tell us that architectural decisions like the split-up of a system into "Bounded Contexts" should be driven by the requirements of a system. However, it is indeed quite normal that software designs follow much more the communication structure of the organization who creates that design. The name for this is Conway's Law, and it is about 50 years old.

This is not necessarily a bad thing as long as it works for you and your organization in context of your current project. However, keep in mind that some tasks can be solved better by adopting the team's structure to the task instead of doing it the other way round.

Answer 2

Keeping functions in the same bounded context together in the user interface too makes sense to me. You could use the modularization of modern frameworks to split the UI into teams: e.g. Angular4 is mostly based on alternating components. For example, you could have:

• a user management page
• a time management page

in the same application, both as unique components being worked on at the same time. You probably can't seperate it completely, however: if you want to have everything in one application, things like Authentication/Authorization should be implemented in (mostly hidden) components applied to all pages of the application; meaning you either need to have a team dedicated to working on these context-overlapping functionalities or have every team work on them, which could become difficult to coordinate. You also have the option of seperating the UIs completely and putting them into different frontends, but that would be way more cumbersome for the end user.