How do you apply design patterns to different architectures?

Using a monolithic architecture is often the first step in implementing an MVP or first iteration of a system because of the ease in developing and testing. Our goals in selecting design patterns here are more focused on easing later decomposition rather than on coordination and orchestration that we see in distributed architectures. This is why we see patterns like layering, modules, facades, and dependency injection - they are all focused on separation of concerns and decoupled independent functioning. They make it much easier to break out functionality if and when needed.

Exposing interfaces across modules via a facade would also typically require the use of Factory pattern (instantiation and discovery of the interface) as well as Singleton pattern(single instance of the fa?ade implementing the interface).

Monolithic architectures offer unified simplicity, making early-stage development smooth with a single codebase, easy testing, and optimized performance. Their cohesive nature ensures atomic transactions and reduces network overhead. However, as they grow, these systems may grapple with scalability and adaptability. Scaling can be resource-intensive, and a minor error might cause system-wide disruptions. Plus, being tied to a single tech stack can limit innovation. While monolithic designs are ideal for some projects due to their initial simplicity, it's crucial to consider future scalability and tech flexibility when adopting this approach.

When choosing the right architectural pattern you should always consider and evaluate these aspects: Application Size, Team Competency and Infrastructure. When creating a straightforward application, a prototype, or an MVP, the monolithic approach is usually more appropriate because it enables developers to construct the software without integrating several services. Monolithic applications have a single code base and framework, which promotes unified simplicity in early-stage development. Additionally, testing is made easier, and performance is improved. However, as they expand, these systems may encounter difficulties with scalability and adaptability.

Monolithic architecture has the potential to enhance its quality and maintainability, but it's crucial to carefully manage the degree of modularization, separation of responsibilities, and the resulting system complexity in order to fully realize the advantages these patterns offer.

The patterns we use in a distributed microservice architecture are to address the challenges of coordination, communication, and control in a distributed system. These patterns give us techniques to help us align with the microservice design principles and still implement a reliable and efficient system. Without them we can end up with tightly coupled services very easily.

Microservices are great but as creators of microservices we must ask 1 question to ourselves "When is the right time to create microservices and do we really need separate microservices for each DDD entity "? Every product goes through phases - MVP -> Scaleable->Platform deciding which microservices we need at which stage is the key for successful microservices implementation

Whenever you are thinking about microservices architecture think about decomposition into services,communications and coordination among services.Each services must follow the SRP and CCP principles Microservices must be architect by keeping in mind about design for failure,decentralization,redundancy and most importantly Isolation.

As the product and teams grow, the monolith architecture become a bottleneck towards the productivity of the organization. For reference, this can happen when the engineering team reaches beyond 500+. At this stage, it might be best to graduate the product to a microservices based architecture, make services isolated and independent of each other. This helps teams to move faster as they do not have to depend on the complete product to be build, instead team can independently control the development cycle of individual product services. This approach however leads to more engineering complexity as each team that owners a part of a product a service, now needs tooling as part of ci/cd to push code to production.

I prefer using term Event Driven Architectures for this. The design patterns we see here are about taming the complexity of now having all the units of business logic - that we previously managed in a microservice or using things like componentisation in a monolith - as the unit of construction. We see many business process design and systems thinking parallels here. Patterns are concerned with managing the flow of data (events) through the system. We have distinct units of work that need to be routed and executed. Queueing Theory is core to all the patterns we use to achieve flow control.

I would add more information about the event-driven architecture approach that this text suggests when talking about serverless. An event-driven architecture is employed to initiate and facilitate communication between decoupled services. Events, which represent changes in state or updates, are used for this purpose. Events can contain the state itself or simply act as identifiers for notifications. The architecture comprises three primary elements: event producers, event routers, and event consumers. Producers publish events to the router, which then filters and distributes them to consumers. The producer services and consumer services are decoupled, enabling independent scalability, updates, and deployments.

One common caveat for turning microservices architecture to serverless is to turn it into a punch of functions and deploy them independently. This is not a good solution since it makes testing hard, multiplies in a number of stacks, and is logically wrong. None of the functions would be functional alone. One microservice turns into 5-7 separate functions, which you should group.

As with every design decision we need to understand the reason behind making use of a certain design pattern. In choosing which ones to use in each different architecture it comes down to what we want the pattern to help us achieve. Also, many of these patterns have evolved from usage. They will continue to evolve so we need to be flexible in our approach and temper our zeal for perfection with a solid dose of practicality.

From my personal observations, numerous developers tend to craft software solutions utilizing frameworks that, owing to their generalized characteristics, inherently impose certain design patterns. Employing domain-driven design principles and anticipating future advancements can provide valuable guidance when selecting appropriate design patterns for different modules. To illustrate, consider the implementation of events within a monolithic solution with the intention of enhancing decoupling. This strategic choice lays a foundation for the seamless integration of a message broker such as RabbitMQ or Kafka at a later stage within the architecture.

This might be fascinating to include a nanoservice architecture in addition to the above elements. Nanoservices can offer numerous benefits in terms of ultra-low latency and high throughput compared to the microservices architecture.

There are some new patterns emerging that are beyond serverless. For example, step functions, lambda based architecture, db proxy based on ui development.