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.


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.

Cloud Native: Evolution Story of Software Infrastructure

On its journey to produce DevOps experts, iauro has got its hands around one of the most revolutionary infrastructures of our times – Cloud Native. Native Infrastructure has been attracting attention recently owing to the situation that the industry is forced into. We therefore decided to share our knowledge on the subject in detail and depth, with a series of articles. We deemed it right to start with talking more about what Infrastructure is and how we arrived at the cloud. This journey has a lot of insights about how administration has also evolved around this subject. Let us begin.

An Introduction to  Infrastructure

Every application needs an anatomy of software and hardware that can provide all the required assistance for its execution. This anatomy, called Software Infrastructure, typically consists of:

  • Operating System
  • Data Repository
  • Configuration Management
  • Deployment Pipeline
  • Additional software hardware specific to the application needs

The modern day applications are evolving to Native Infrastructure. However, that wasn’t always the case. While we will talk more about cloud later in this article, let us first go to the very beginning of the infrastructure’s journey and see how it all started.

The Initial Space

In order to produce and run large scale software, organizations needed a lot of space. By space, we mean, actual physical rooms. These rooms had to be air-conditioned, sealed and very very skeptical of human intrusion. We’re talking about the times when infrastructure was provided by Servers. These big, noisy and very expensive electronic machines required a lot of power and people to keep them running. In return, here’s how they ‘served’

  • As per the business requirements, they could be configured to provide storage space, operation environment, development resources etc.
  • Servers are very powerful. With relatively low failure rates they can last a very long time 
  • Servers are essentially the pioneers of applications infrastructure. They laid the basis for the future infrastructure technologies to thrive.

The physical existence of servers was their biggest disadvantage. They were so big that buying them was actually a capital expenditure for the organization. Apart from that there were a few functional disadvantages too. To name a few

  • Running Multiple applications at large scale was difficult
  • Network Routing was complicated as the number of applications and user increased
  • Multiple users accessing the server also slows down its performance drastically

The Virtual Solution

The next logical step from server was to attain their physical space in a virtual environment. This kind of infrastructure was, in fact named Virtualization. It was a helpful step because

  • Virtual servers are configurable on software so the physical resource utilisation is reduced. 
  • These Virtual Machines (VMs) are essentially emulators for physical servers, so they practically never wear out.
  • One server can run multiple VMs
  • Portability was introduced to infrastructures as VMs could be moved between different servers

Virtualization was definitely a step forward. The only problem was that the companies still needed to spend on servers and the resources to maintain them. The number of servers was reduced thanks to VMs but the necessity was still there. 

Infrastructure as a Service

Infrastructure as a Service (IaaS) was the primitive step that evolved into Native Infrastructure. 

IaaS was provided in the form of a networking, storage and computation environment which could be consumed on demand. Additional services like provisioning and inventory management were also handled by this infrastructure. Essentially, the organization could get rid of all the hardware and get its VMs from third parties on demand. The benefits were obvious:

  • Less Physical space required along with reduced expenditure on maintenance resources.
  • The service was accessed using Application Programming Interfaces (APIs). API calls were fast and could be easily manipulated as per requirement

This was a new idea and organizations were still not able to completely shift towards it. In fact, many companies used IaaS in a traditional way by creating space for their own servers and using them to create the services.

Platform as a Service

Platform as a Service (PaaS) were more of a complement to IaaS rather than a step ahead. While IaaS hid the physical servers, PaaS were meant to abstract the operating system. However, there was one thing that cleared the way for Native Infrastructure.

PaaS made application development platform independent. This meant that the developer were free to write their code without worrying about anything but the business logic that was expected from that code. This led the development lifecycle into a new generation. New business ideas emerged and new ventures were start up and small organizations were a little relieved from the overhead of physical space and other similar expenses. This was also the time when Public PaaS providers emerged in the market. PaaS had given birth to a new business vertical altogether

Moving to the Clouds

The stage was set. Infrastructure had become an operational expense rather than a capital one. Since, operational costs are billed by the time of consumption the aim was now to minimize this time. This lead to a revolutionary infrastructure technology – Native Infrastructure. Clouds have abstracted everything. They are a combination of IaaS and PaaS with additional features. They are controlled by APIs and softwares and can scale to a very large number of users. Apart from this, there were other benefits like:

  • They can work with more complex technologies meant for automation, Internet of things, etc.
  • The APIs could be managed by role based access making the clouds the most secure infrastructure so far.
  • This is a scalable infrastructure in every sense. It provides scalability in terms of:
    • Development
    • Operation
    • Provisioning and
    • Maintenance

Cloud Native Infrastructure has reached us after a long chain of evolutions. During this course, the surrounding technologies have also evolved to be more flexible, efficient and technology agnostic. Native Infrastructure is necessary now more than ever. Working with distributed teams that are spread across multiple regions cannot be possible without a support like this. In the subsequent articles we will talk in detail about clouds, their core principles and their benefits. Stay tuned.