Imagine breaking down a single functional unit into multiple mini-service units. That is exactly what microservices do to the traditional monolithic architecture. But there is more to it than meets the eye. Microservices are the go-to solution for all the major software development projects.
But even though it serves a major purpose, certain challenges must be addressed. As one designs a microservice architecture along the way, one learns several microservice design patterns, which can improve performance and ease the developer’s life. There is an increasing demand for knowledge about microservices design patterns as the adoption of microservices architecture increases among organizations. Let us learn about the various microservices design patterns in detail.
Check out the Monolithic vs Microservices debate to uncover the pros, cons, and key distinctions between the two architectures and navigate your choices wisely!
What are Microservices Design Patterns?
A microservices design pattern is a collection of practices and tried and true solutions to common issues in microservices architecture’s design, deployment, and maintenance. It provides a structured approach to solving recurring issues, such as service communication, fault tolerance, scalability, etc. It helps to ensure that microservices work seamlessly in a cohesive and resilient manner. By leveraging these patterns, developers can streamline microservices’ design, implementation, and management and foster a robust and efficient distributed system.
Microservices design principles provide a comprehensive guideline for designing scalable and maintainable microservices architectures. Some important microservice principles are API Integration, Traffic Management, Data Storage Segregation, Unique Source Of Identification, etc.
Easily compare text files with our **text compare** tool. Try it now!
Top Microservices Design Patterns
Various patterns like the event-driven pattern, saga pattern, bulkhead pattern, event sourcing design pattern, etc., help us solve collaboration, performance, deployment issues, etc.
Let us delve into the essential patterns that empower developers to build an agile, resilient, scalable, and robust microservices architecture.
Microservices Design Patterns for Effective Collaboration
Collaboration is necessary for running an efficient microservice architecture with so many microservices running simultaneously. Let’s look at the collaboration patterns for designing a microservice and understand them in detail.
Aggregator Microservice Design Pattern
Since multiple services are involved, the output must be fetched and combined for the end user. To integrate the data, a user will need a lot of internal knowledge about the system. Since we design microservices architecture, decomposing the monolith means dividing the output sources. That’s why we use the aggregator pattern to aggregate this data.
The aggregator microservice design pattern consolidates data from multiple microservices into a unified result for an end-user. By acting as a single point of contact, this pattern helps fetch and combine the necessary information from various microservices instead of the client making multiple requests. This pattern promotes efficiency, reduces network latency, and simplifies the client’s interaction with the microservices ecosystem.
The user initiates a request by sending it to the aggregator microservice. Upon receiving the request, the aggregator identifies the relevant data sources needed to fulfill the user’s request and sends individual requests to each identified data source. These data sources then respond to the aggregator microservice with their respective data. Once all responses are collected, the aggregator microservice aggregates the data from all sources into a cohesive form. Finally, the aggregator microservice sends the aggregated data back to the user as a response to the original request.
The solution can be forwarded to the end user through two major components: composite microservice and API gateways. Composite microservices involve grouping multiple smaller microservices to provide cohesive, higher-level functionality. API gateways serve as a unified entry point for external clients to access and interact with microservices. Either of the components will aggregate the data and forward it to the user. However, composite microservices should be preferred if business capabilities are used in decomposing the system.
Branch Microservice Design Pattern
The branch microservices design pattern extends the aggregator design patterns. It enables concurrently processing requests and responses from two or more distinct and mutually exclusive chains of microservices.
In the above example, service A communicates with multiple services simultaneously.
This design pattern also offers the flexibility to summon separate multiple chains or even a single chain as per the business needs. In the case of an e-commerce website or web application, we need to retrieve data from multiple sources belonging to different microservices. This is where the branch microservice design pattern plays an effective role.
Convert strings to JSON format effortlessly with our **string to json** tool. Check it out!
API Gateway Microservice Design Pattern
Fetching data from running services is crucial for any application, especially in a microservices architecture. Extracting data from individual services is vital, but presenting user-owned resources from multiple microservices through a single UI can pose challenges. An API gateway acts as a single entry point, managing tasks like routing, composition, and protocol translation within the architecture.
The above scenario shows that the API gateway collects client requests in a single entry point and routes requests to internal microservices. As a single source of contact, it can act as a proxy server to route requests to microservices, aggregate results from multiple services, and send the output to the user. It can handle multiple protocol requests and convert whenever required. (eg. HTTPS to AMQP and vice versa). It also helps establish security by client authorization and exposes relevant APIs concerning the client.
Backend for Front-End(BFF) Microservice Design Pattern
Backend for Front-End (BFF) is a subset of the API Gateway microservices design pattern. It involves creating a dedicated backend service tailored to the specific needs of a front-end application or client. This pattern ensures a more efficient and streamlined interaction between a system’s frontend and backend components.
Consider an e-commerce platform that serves both web and mobile applications. Implementing the Backend for Front-End (BFF) pattern in this scenario involves creating dedicated backend services for each front-end application. The web application’s BFF will optimize APIs for large-screen displays, while the mobile app’s BFF could tailor APIs for a smaller screen and different user interactions. And there will be another BFF for 3rd party services called public BFF. All these BFFs interact with the downstream services.
This pattern enhances collaboration by allowing frontend and backend development teams to work independently and more efficiently. Frontend developers can focus on building a user interface using APIs tailored precisely to their application’s requirements, while backend developers can concentrate on providing optimized and specialized services.
The Event-Driven Microservice Design Pattern
The Event-Driven pattern is a powerful microservices design pattern that facilitates asynchronous communication and collaboration among distributed components. In this pattern, microservices communicate through events, allowing them to operate independently while responding to specific occurrences or changes in the system.
The Event-Driven pattern employs a publisher-subscriber (PUB/SUB) model, where microservices act as either event producers or consumers. This decoupling ensures that services remain loosely interconnected, enhancing scalability, maintainability, and flexibility. By relying on events, microservices don’t need to be aware of each other, reducing direct dependencies and promoting autonomy. This results in a more collaborative architecture where services can evolve independently, responding to events as needed, and contributing to an agile and resilient microservices ecosystem.
The event-driven microservices design pattern uses three main components: the producer, consumer, and broker. The producer initiates events and publishes them to a central hub known as the broker. Consumers subscribe to specific events they are interested in and react accordingly when they receive them. Meanwhile, the broker manages the routing, filtering, and delivery of events to ensure efficient communication between producers and consumers.
For instance, in an e-commerce platform, the order service is a producer that sends an event trigger to the message broker, and the payment service, stock service, and email service are consumers who will consume the events from the message broker. When a new order is placed, an event can be triggered, leading to various microservices updating inventory, processing payments, and sending order confirmations.
Asynchronous Messaging Microservice Design Pattern
The asynchronous messaging microservices design pattern plays a crucial role by allowing microservices to communicate without requiring sequential interaction. By decoupling services through asynchronous communication, we can foster effective collaboration in a microservices architecture, as services can now independently process and respond to messages at their own pace, promoting flexibility and autonomy.
Asynchronous messaging pattern allows microservices to communicate indirectly through a message queue. When a microservice wants to send a message, it publishes it to a message queue without waiting for an immediate response from the receiver. The message queue stores the message until the receiver is ready to process it.
For example, in an e-commerce system, when a new order is placed, the order processing service sends a message to the inventory service with the help of a message queue, allowing it to independently and asynchronously handle its tasks, promoting autonomy and efficient collaboration between the microservices. While this scenario may resemble the event-driven pattern, it differs in that, with asynchronous messaging, messages are directed specifically to intended recipients via the message queue, whereas in event-driven architecture, all subscribed consumers receive event notifications broadcasted by the message broker.
Chained or Chain of Responsibility Microservice Design Pattern
In the chained or chain of responsibility microservices design pattern a sequence or chain of microservices, each responsible for a specific task in sequence. For example, a chain could include microservices responsible for order validation, payment authorization, and fulfillment in an order processing system. As a new order traverses the chain, each microservice collaborates seamlessly to perform its designated task.
This microservices design pattern promotes modularity and allows various teams to independently develop and maintain specific processing units, enhancing collaboration in building and evolving the system.
Extract phone numbers quickly using our **phone number extractor**. Try it today!
Bulkhead Microservice Design Pattern
The bulkhead microservices design pattern is named after the compartments (bulkheads) in ships that prevent the entire vessel from sinking in case of a breach. In the context of microservices, the bulkhead pattern involves segregating components or services into isolated compartments that help to prevent failures in one compartment from affecting others.
The pattern helps to promote effective collaboration by isolating failures within specific compartments. If one microservice experiences issues or becomes overwhelmed, the failure is contained within its bulkhead, preventing a domino effect that could impact the entire system. This isolation enhances the overall stability of the microservices architecture and supports collaborative efforts by minimizing the scope of potential disruptions.
Sidecar Microservice Design Pattern
The Sidecar Microservice Design Pattern is an architectural pattern that enhances the functionality and capabilities of a primary service by deploying an auxiliary service, known as a “sidecar,” alongside it. It allows the main service to focus on its primary functionality while offloading certain auxiliary tasks to the sidecar.
Consider a microservices architecture with a main application service responsible for handling HTTP requests. To enhance security, we deploy a dedicated sidecar service alongside it, acting as an authentication proxy. The sidecar can then handle tasks like user authentication, token validation, and enforcing security policies.
Applying this pattern helps us to foster collaboration in microservices by promoting a clean and modular separation of concerns. With dedicated sidecar services managing common concerns like logging, monitoring, or security, each microservice can concentrate on its core logic. This modular architecture encourages independent development, scalability, and the reusability of specialized functionalities, enabling efficient collaboration among development teams working on different aspects of the microservices ecosystem.
To unlock the full potential of your microservices architecture with effective testing strategies, dive into our *Microservices Testing Tutorial* and *Microservices Testing Quick Start Guide*!
Microservices Design Patterns for Performance Monitoring
Monitoring performance is an essential aspect of a successful microservice architecture. It helps calculate the efficiency and understand any drawbacks slowing the system down. Remember the following patterns related to observability for ensuring a robust microservice architecture design.
Log Aggregation Microservice Design Pattern
When referring to a microservice architecture, we refer to a refined yet granular architecture where an application consists of several microservices. These microservices run independently and simultaneously, supporting multiple services and their instances across various machines. Every service generates an entry in the logs regarding its execution. How can we keep track of numerous service-related logs? This is where the log aggregation microservices design pattern steps in. In this pattern, we collect and consolidate log data generated by various microservices, allowing for centralized monitoring, analysis, and troubleshooting of the entire microservices architecture.
As a best practice to prevent chaos, we should have a master logging service. This master logging service should aggregate the logs from all the microservice instances. This centralized log should be searchable, making it easier to monitor.
Synthetic Monitoring, a.k.a Semantic Monitoring Microservice Design Pattern
Monitoring is a painful but indispensable task for a successful microservice architecture. With the simultaneous execution of hundreds of services, it becomes troublesome to pinpoint the root area responsible for the failure in the log registry. Synthetic monitoring gives a helping hand here.
In this microservices design pattern, we simulate user interactions with a system to assess its performance and functionality. In this approach, synthetic scenarios are created to mimic real user behavior. When we perform automated tests, synthetic monitoring helps to regularly map the results compared to the production environment, and the user gets alerted if a failure is generated.
We can easily monitor automated test cases and detect production failures regarding business requirements using semantic monitoring. This allows organizations to identify issues before they impact actual users proactively.
API Health Check Microservice Design Pattern
Microservice architecture design promotes services that are independent of each other to avoid any delay in the system. APIs, as we know, serve as the building blocks of online connectivity. It is imperative to keep a health check on your APIs regularly to realize any roadblocks. It is often observed that a microservice is up and running yet incapacitated for handling requests. This can be due to many factors like server load, user adoption, latency, error logging, market share, and downloads.
To overcome this, we can use the API health check microservices design pattern to assess and monitor the health and performance of individual APIs within a system. This helps to identify potential issues, ensure the responsiveness of microservices, and maintain overall system performance.
We should ensure that every service running must have a specific health check API endpoint. For example, when appended at the end of every service, HTTP/health will return the health status for the respective service instance. A service registry periodically appeals to the health check API endpoint to perform a health scan. The health check would provide us with the following details:
A logic that is specific to the application.
Status of the host.
Status of the connections to other infrastructure or connection to any service instance.
Circuit Breaker Microservice Design Pattern
The circuit breaker pattern is similar to an electrical circuit breaker in our home. When there’s a fault, the breaker trips, isolating the faulty circuit and preventing further damage. Similarly, in a microservices architecture, the pattern detects service failures and temporarily breaks the circuit, preventing the spread of issues and ensuring overall system resilience.
In this microservices design pattern, the circuit breaker trips when a predefined threshold of failures is reached, preventing further requests from being sent to the failing microservice. This helps monitor and manage the overall system performance and resilience by preventing the cascading failure of microservices.
A circuit breaker has three states for reliability: “Closed” when the monitored service functions well, “Open” when issues arise, blocking requests to prevent overload, and “Half Open” when the service shows signs of recovery, allowing limited requests to test its functionality before fully reopening.
The circuit breaker microservices design pattern can be used in various places like an e-commerce system; if a product recommendation microservice starts experiencing high latency or errors due to increased traffic, the circuit breaker can transition to an open state. During this state, requests for recommendations are directed to a fallback mechanism, such as showing popular or recently viewed products. This prevents the degradation of the entire user experience and allows the system to recover without overwhelming the struggling microservice.
Microservices Design Patterns for Business Purposes
‘Decomposing’ a monolithic architecture into a microservice must follow certain parameters. These parameters have a different basis. Today, we will look at the decomposition of the microservice design patterns, which leave a lasting impact.
Convert HEX colors to CMYK easily with our **hex to cmyk** tool. Use it now!
Unique Microservice for each Business Capability
A microservice is as successful as its high cohesion and loose coupling combination. Services need to be loosely coupled while keeping the function of similar interests together. But how do we do it? How do we decompose a software system into smaller independent logical units?
We do so by defining the scope of a microservice to support a specific business capability.
For example, in every organization, different departments come together as one. These include technical, marketing, PR, sales, service, and maintenance. To picture a microservice structure, these domains would each be the microservices, and the organization would be the system. So, inventory management is responsible for all the inventories. Similarly, shipping management will handle all the shipments and so on.
To maintain efficiency and foresee growth, the best solution is to decompose the systems using business capability. This includes classification into various business domains responsible for generating value in their capabilities.
Microservices around similar Business Capability
Despite segregating based on business capabilities, microservices often come up with a greater challenge. What about the common classes among the services? Composing these classes, known as ‘God Classes, ’ needs intervention. For example, in the case of an e-commerce system, the order will be common to several services such as order number, order management, order return, order delivery, etc. We turn to a common microservice design principle known as Domain-Driven Design (DDD) to solve this issue.
In Domain-Driven Design, we use subdomains. These subdomain models have a defined scope of functionality known as bounded context. This bounded context is the parameter used to create each microservice, thus overcoming the issues of common classes.
Strangler Vine Microservice Design Pattern
While we discuss the decomposition of a monolithic architecture, we often miss out on the struggle of converting a monolithic system to design microservice architecture. With the work being hampered, converting can be manageable. Based on the vine analogy, we have the strangler pattern to solve this problem. Here is what the Strangler patterns mean in Martin Fowler’s words:
“One of the natural wonders of this area [Australia] is the huge strangler vines. They seed in the upper branches of a fig tree and gradually work their way down the tree until they root in the soil. Over many years, they grow into fantastic and beautiful shapes, meanwhile strangling and killing the tree that was their host.”
Like a strangler vine slowly envelops and replaces a host tree, this pattern allows organizations to evolve their systems incrementally rather than opting for a risky and disruptive Big Bang migration. New microservices are introduced alongside the existing monolith to handle specific functionalities. Over time, new features are developed, or existing ones are refactored and implemented as microservices.
The strangler microservices design pattern is extremely helpful in the case of a web application where breaking down a service into different domains is possible. Different services live on different domains since the calls go back and forth. So, these two domains exist on the same URI. Once the service has been reformed, it ‘strangles’ the existing version of the application. This process is followed until the monolith doesn’t exist.
Saga Microservice Design Pattern
The saga pattern is a microservices design pattern used to manage distributed transactions within a microservices architecture. It addresses the challenges of maintaining data consistency across multiple services involved in a complex operation by breaking down a transaction into smaller, more manageable steps. Each step in the saga corresponds to an operation within a microservice, and these steps are coordinated to ensure eventual consistency.
Consider an online hotel booking where a customer initiates a reservation. Here, the saga pattern breaks down the transaction into steps handled by different microservices: creating the reservation, charging the customer, and sending a confirmation email. When the payment step fails due to a temporary issue, the saga pattern enables compensating transactions to be executed. This could involve returning the room to the inventory and implementing a retry mechanism for the payment.
By managing distributed transactions and ensuring consistency, the Saga microservices design pattern aligns with business goals by maintaining data accuracy and reliability. It supports critical business processes that span multiple microservices.
Convert CMYK colors to HEX format effortlessly with our **cmyk to hex** tool. Try it here!
Backend for Front-End(BFF) Microservice Design Pattern
The BFF pattern enables the creation of backend services that align closely with specific business requirements and user interfaces. This tailored approach ensures that the APIs provided by BFF services are finely tuned to the unique needs of each front-end application. The pattern promotes a business-centric approach by facilitating the development of microservices that directly serve the needs of specific applications, ultimately enhancing the overall effectiveness and agility of the microservices architecture.
For instance, in an e-commerce platform, the BFF for the web application might prioritize features such as advanced product filtering. At the same time, the BFF for the mobile app could focus on providing a seamless and efficient checkout process. This fine-grained customization allows businesses to optimize user experiences, implement targeted functionalities, and meet distinct business goals by strategically using BFF services.
The Event-Driven Microservice Design Pattern
The Event-Driven pattern enables real-time responsiveness to critical business events. This pattern is particularly valuable when certain business processes must be triggered or updated immediately in response to specific events. For instance, an event-driven approach could be employed in a banking application to instantly update account balances, trigger fraud detection mechanisms, or notify customers of transaction confirmations.
By harnessing the Event-Driven Pattern, businesses can seamlessly incorporate dynamic and event-triggered functionalities into their microservices architecture, ensuring timely and relevant responses to changing business conditions. This pattern enhances the adaptability and agility of microservices in addressing diverse business requirements and fostering a more responsive and customer-centric system.
Chained or Chain of Responsibility Microservice Design Pattern
By applying the chained or chain of responsibility microservices design pattern, businesses can model complex workflows in a modular and maintainable manner. Each microservice in the chain will be responsible for a specific business need, contributing to the overall business process. This enhances adaptability to evolving business requirements, as changes or updates can be made to individual microservices without affecting the entire system.
Circuit Breaker Microservice Design Pattern
From a business perspective, the circuit breaker pattern safeguards continuous operations and protects revenue streams. Preventing the cascading impact of microservice failures contributes to business continuity, critical for maintaining customer satisfaction and trust. The pattern not only shields against potential revenue loss caused by service disruptions but also safeguards brand reputation by providing a reliable and resilient user experience.
In essence, the Circuit Breaker Pattern aligns closely with business goals by fostering reliability, minimizing downtime, and fortifying the overall health of microservices to support sustained business success directly.
Sidecar Microservice Design Pattern
The sidecar microservices design pattern greatly aids in implementing business logic within microservices by enabling a focused and modular approach to development. The main microservice can exclusively concentrate on its core business logic by delegating common concerns to dedicated sidecar services. This separation ensures a clean and maintainable codebase, allowing independent updates and scalability of the business logic without unnecessary entanglement with auxiliary functionalities.
The pattern also enhances agility in adapting to evolving business requirements, facilitating a more efficient and streamlined development process.
Microservices Design Patterns for Optimizing Database Storage
For a microservice architecture, loose coupling is a basic principle. This enables the deployment and scalability of independent services. Multiple services might need to access data not stored in their unit. However, accessing this data can be challenging due to loose coupling. Mainly because different services have different storage requirements, and access to data is limited in microservice design. So, we look at some major database design patterns per different requirements.
Individual Database per Service
Usually applied in domain-driven designs, one database per service articulates the entire database to a specific microservice. Due to the challenges and lack of accessibility, a single database per service needs to be designed. This data is accessible only by the microservice and the database has limited access to outside microservices. The only way for others to access this data is through microservice API gateways.
Shared Database per Service
In domain-driven design, a separate database per service is feasible, but using a single database can be tough when you decompose a monolithic architecture into a microservice. So, while the decomposition process continues, implementing a shared database for a limited number of services is advisable. This number should be limited to two or three services. This number should stay low to allow deployment, autonomy, and scalability.
Event Sourcing Microservice Design Pattern
According to Martin Fowler:
“Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not only can we query these events and use the event log to reconstruct past states but also use it as a foundation to adjust the state automatically to cope with retroactive changes.
The problem here lies with reliability. How can you rely on the architecture to make a change or publish a real-time event concerning the changes in the application’s state?
Event sourcing helps to come up from this situation by appending a new event to the list of events every time a business entity changes its state. Entities like Customer may consist of numerous events. It is thus advised that an application saves a screenshot of the current state of an entity to optimize the load.
CQRS Microservice Design Pattern
The query cannot be implemented in a database-per-service model because of the limited access to only one database. For a query, the requirements are based on joint database systems. But how do we query then?
Based on the CQRS(Command Query Responsibility Segregation), to query single databases per service model, the application should be divided into two parts: Command(write) and Query(read). In this model, the command handles all requests for creating, updating, and deleting, while queries are handled through a materialized view. These views are updated through a stream of events. These events, in turn, are created using an event-sourcing pattern that marks any data changes. These changes eventually become events.
CQRS is particularly beneficial in scenarios where the read and write patterns differ significantly, allowing for more flexibility and optimization in handling each type of operation. While it introduces complexity, it provides advantages in scalability, performance, and adaptability to varying system requirements.
Convert HEX values to decimal easily with our **hex to decimal** tool. Check it out!
Microservices Design Patterns for Seamless Deployment
When we implement microservices, certain issues arise during the call of these services. When we design microservice architecture, certain cross-cutting patterns can simplify the working.
Service Discovery
The use of containers leads to dynamic allocation of the IP address. This means the address can change at any moment. This causes a service break. In addition, the users have to bear the load of remembering every URL for the services, which become tightly coupled.
A registry needs to be used to solve this problem and give users the location of the request. While initiation, a service instance can register in the registry and de-register while closing. This enables the user to find the exact location that can be queried. In addition, a health check by the registry will ensure the availability of only working instances. This also improves the system’s performance.
Blue-Green Deployment Microservice Design Pattern
Whenever updates are to be implemented or newer versions are deployed, one has to shut down all the services in a microservice. This leads to a huge downtime, thus affecting productivity. To avoid this issue, use the Blue-Green Deployment pattern when designing microservice architecture.
In this microservice design pattern, two identical environments, Blue and Green, run parallelly. The existing version of the application, i.e., the current production environment, is often referred to as “Blue,” and it actively serves user traffic. The duplicate environment is set up with the new application version or updates and is often called “Green”. This environment mirrors the production setup but receives no user traffic initially. At a time, only one is live and processing all the production traffic. In case of a new deployment, one uploads the latest version onto the green environment, switches the router to the same, and thus implements the update.
This deployment strategy is particularly valuable in microservices architectures, where various services may need to be updated independently, and maintaining service availability is critical.
Externalized Configuration Microservice Design Pattern
Externalized Configuration is a microservices design pattern where configuration settings for an application are stored outside the codebase, typically in configuration files, environment variables, or centralized configuration servers. Instead of hardcoding configuration parameters, this pattern allows for dynamic and centralized control of application settings, making it easier to manage and modify configurations without requiring code changes.
This pattern helps in flexibility and enhances the maintainability and scalability of the system, as configuration changes can be applied independently of the codebase, facilitating a more agile and adaptable architecture.
API Gateway Microservice Design Pattern
API gateway provides a unified entry point for clients while abstracting the underlying complexities of the microservices architecture. During deployment activities, when updates or changes are made to individual microservices, the API Gateway shields clients from potential disruptions. Clients can continue interacting with the API Gateway without being aware of the modifications occurring in the backend. This abstraction allows for rolling updates and new versions of microservices can be gradually introduced without affecting the overall system availability.
The API gateway also ensures a smooth transition by dynamically routing requests to the appropriate microservices, thus minimizing downtime and ensuring a seamless user experience during deployment.
Check out our blog on Testing Challenges With Microservices Architecture to uncover insights, solutions, and best practices.
Conclusion
Though only some design patterns might apply to a given microservice, you can rest assured that most of them will be used everywhere. These design patterns help developers bring in a consistent standard that brings reliability to the application. As organizations navigate the complexities of microservices architecture, a solid understanding of these design patterns becomes imperative for building robust and adaptable systems that align with business goals.
The evaluation, auditing, implementation, and testing of microservices of these design patterns are an ongoing process of microservice architecture. These patterns will help throughout, from the designing phase of the application to the maintenance phase in production.
Top comments (0)