Domain Driven Design to Frontend Development

Modularity makes the development process faster and the application better. The goal of the freshly arrived Microfrontends technology is to extend this modularity aspect to the frontend development. This will in turn maximize the effect of what is called – Domain Driven Design. Let us take a look at how this extension is possible and how it is necessary now more than ever.

Understanding the Modules

Well-thought modules build a flexible and more efficient application. The ultimate features of the application are divided into multiple knowledge contexts or domains and each module is then developed by the team of experts for its corresponding domain. This is the core idea behind Domain Driven Design (DDD). The knowledge context  may vary depending on the type of application or services being developed, but the effects of modularity are pretty much the same.

A revolutionary technology that de facto enforced DDD in application development, is the Microservices Architecture (MSA). Owing to the MSA, the applications and services can be developed using modules that are:

  • Decoupled but connected through strong intercommunication
  • Heavily Object-oriented
  • Easily developed and deployed by independent domain expert teams

The modules developed under the DDD approach are independently deliverable and can be treated as small services of their own; hence, the name microservices. Though, MSA can only help the application modules to be domain driven from the backend. The frontend development was still following the monolithic architecture. 

Challenges for Monolithic Frontend

This is the time for Single Page Applications (SPAs). These applications don’t ask the server to send pre-processed HTML pages every time some data is refreshed by the client. They take the pure data stream from the server and refresh the presentation on their own. This is great for the application’s performance as it is not slowed-down by multiple server requests. The feature wasn’t possible without the modularity provided by MSA and the developers’ world is thankful for that. However, since some of these applications still work on monolithic frontends, the MSA is not able to realize its full potential. In turn, have to work around the challenges like:

  •  Development Challenges: The codebases are complex in every sense of the word. They are hard to develop, unsupportive of concurrency,  and highly coupled. All of these are the phrases developers hate very much. Moreover, distributed teams don’t go well with monolithic frontends as well.
  • Decisional Challenges: Any decision related to the architectural or feature update is bound to affect the whole frontend monolith. The microservices can be easily modified. But since the frontend is basically a single unit, every update feels like less of an improvement and more like a repairment
  • Operational Challenges: Although the SPAs do well with MSA yet the overall performance of the application is still sluggish. The single page basically has to be refreshed as a whole instead of manipulating the area of interest.

Therefore, the frontend developers need an architecture that extends the domain approach to the presentation layer as well. The SPAs will thus be working with independent modules through and through. This is where the Micro frontend Architecture (MFA) finds its way in.

Micro frontend Architecture for Domain Driven Design

MFA can be understood as an extension of the MSA principles for frontend development. Just like microservices, here independently deliverable frontend applications come together to build up to serve a larger application. The development and assimilation of microfrontend units is domain driven, making the frontend and backend compliment each other rather than slowing each other down. Therefore, with the help of this architecture the applications can enjoy:

  • Decoupled Development: Code for the smaller frontend units will be rather simpler and independent of other units. The data and events can flow explicitly among the application modules without any accidental or deliberate coupling. In short, the development will be faster and more aligned with the ultimate features of the application. Additionally, the developing teams will also be autonomous in their choices of technology stack, development approach and, of course, quality.
  • Seamless Deployment: Why not! If the MSA can allow hassle free deployment of microservices, Micro frontend architecture can do the same as well. The associated risks of deployment are reduced and continuous delivery pipeline is in effect for building, testing and deploying
  • Incremental upgrades: Instead of working around the regularly updated features, the frontend can evolve with them. MFA allows incremental upgrades so that the whole application can expand without bringing down the whole architecture everytime a new update comes.
  • Modular Performance: Since, the frontend and backend are both domain centric, every data refresh will affect only the modules that are intended for that effect rather than the whole page or application. The SPAs will therefore perform faster and more efficiently.
  • Team Autonomy: Nothing works better than independent teams having the autonomy of tech stack, innovative liberty and development quality. This is domain driven design in full effect.

Conclusion

This was, in fact, first in the series of articles where we talk about MFA in detail. We now know that incorporating Microfrontends in their applications is a positive step by organizations towards Domain driven design. This will not only ensure better performance of their apps and services, but higher productivity and client satisfaction as well. Micro frontend architecture is a secret weapon that organizations can benefit from before even before it explodes in the mainstream market. In the next blog we will extend this conversation to the principles that the MFA follows. Stay tuned.

Leave a Reply

Your email address will not be published. Required fields are marked *