Micro-frontend architecture is about breaking up frontend monoliths into smaller, more manageable pieces, for the purpose of increasing the effectiveness and efficiency of teams working on frontend code. One of the main motivations for working with Microfrontends is the level of isolation that Microfrontends have from each other, especially since it can potentially make teams more autonomous. However, not every decomposition of Frontend monolith would necessarily maximize this potential.

In Agile, development tasks are often derived from user stories. A User Story is a short, simple description of a goal that a user would like to achieve, described from the perspective of the user and in terms of the business. In many systems, resolving a user story often involves the cooperation and coordination of multiply teams, since implementing the story affects different areas of the software which belong to different teams. This phenomenon is highly related to how organizations construct development teams: We usually encounter an arbitrary/artificial division of responsibility between development teams, such as teams owning components, pages, views, classes, or modules. Since this division is not business-oriented in the sense that it is not aligned with how user stories are organized, then it is less likely that the technical tasks that are required to implement a user story would all fall under the responsibility area of a single team.

A straightforward solution to this problem would be to organize teams around business aspects, rather than around technological concerns. This is based on the realization that a complex domain can be decomposed into sub-domains, where each subdomain represents the main business aspect. By splitting the business domain into foreign and complementary sub-domains, one can ensure that each user story would specify a certain business goal that belongs to a certain sub-domain. Together with Conway’s law, which states that organizations tends to mirror their own structure in the software they built, it is reasonable to assume that by organizing teams around business concerns, the resulted software will remain aligned with business concerns as well, and thus, the dichotomy between responsibility areas of different teams will be preserved. Hence, Assigning each team to own the area of the software that supports a single sub-domain might be a good approach for improving teams’ autonomy.

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” — Melvin E. Conway

Although the above realization is applicable on a monolith frontend, a Micro-frontends architecture would enhance this idea, as it enforces stricter segregation among business concerns, as well as among their respective software. Furthermore, a Micro-frontends architecture would deliver teams with additional autonomy, as it would enable them to select their own technological stack and design patterns.

A key takeaway is that it is not absolutely necessary to apply a Microfrontend architecture as a means for organizing teams and software that is aligned with business concerns, although Microfrontends can enhance this idea. On the other hand, if a Microfrontend architecture is being considered, for some reason, then Strategic Domain-driven Design should act as the main guideline in identifying Microfrontends.