π» Event-Driven architecture
Event-driven architecture is a software architecture and model for application design. With an event-driven system, the capture, communication, processing, and persistence of events are the core structure of the solution. It is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. It is also highly adaptable and can be used for small applications and as well as large, complex ones. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events. The event-driven architecture pattern consists of two main topologies, the mediator and the broker. The mediator topology is commonly used when you need to orchestrate multiple steps within an event through a central mediator, whereas the broker topology is used when you want to chain events together without the use of a central mediator. Because the architecture characteristics and implementation strategies differ between these two topologies, it is important to understand each one to know which is best suited for your particular situation. For more information on the architecture I recommend O'Reilly article by Mark Richards.
Event-Driven architecture graph Extensibilityπ£π£π£β«β«Software engineering and systems design principle that provides for future growth.
Configurabilityπ£π£β«β«β«Systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
Portabilityπ£π£π£β«β«Portability in high-level computer programming is the usability of the same software in different environments.
Scalabilityπ£π£π£π£π£Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
Testabilityπ£π£β«β«β«Degree to which a software artifact (i.e. a software system, software module, requirements- or design document) supports testing in a given test context.
Feasibilityπ£π£π£β«β«For a software project to be feasible, it must be possible to complete the work in the time and/or budget dictated. For this reason feasibility touches on a number of other QARs, including time-to-market, total cost of ownership, technical knowledge, and migration requirements.
Deployabilityπ£π£π£β«β«Deployability is the degree of ease with which software can be taken from the development to the production environment.
Elasticityπ£π£π£π£β«The degree to which a system is able to adapt to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible.
Evolvabilityπ£π£π£π£π£Evolvability is the property of systems that can easily be updated to fulfill new requirements; software that is evolvable will cost less to maintain.
Fault toleranceπ£π£π£π£π£Fault tolerance is the property that enables a system to continue operating properly in the event of the failure of one or more faults within some of its components.
Integrabilityπ£π£π£β«β«Process of bringing together the component sub-systems into one system and ensuring that the subsystems function together as a system.
Interoperabilityπ£π£π£β«β«Interoperability is a characteristic of a product or system to work with other products or systems.
Performanceπ£π£π£π£π£The amount of useful work accomplished by a computer system.
Simplicityπ£β«β«β«β«Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. - Edsger W. Dijkstra (1984)
Workflowπ£π£π£π£π£The process of dividing software development work into smaller, parallel or sequential steps or subprocesses to improve design, product management.
π₯ Layered architecture
Layered architectures are said to be the most common and widely used architectural framework in software development. It is also known as an n-tier architecture and describes an architectural pattern composed of several separate horizontal layers that function together as a single unit of software. A major characteristic of this framework is that layers are only connected to the layers directly below them. In the illustration given previously, layer 1 only connects to layer 2, layer 2 connects to layer 3, and layer 1 is connected to layer 3 only through layer 2. Another characteristic is the concept of layers of isolation. This means that layers can be modified and the change wonβt affect other layers. In short, changes are isolated to the specific layer that is altered. Separation of concerns is another notable feature that speaks to how the modules on a single layer together perform a single function. Now, the number of layers in a layered architecture is not set to a specific number and is usually dependent on the developer or software architect. It is important to note that this framework will usually always have a user interaction layer, a layer for processing, and a layer that deals with data processing.
Layered architecture graph Extensibilityπ£β«β«β«β«Software engineering and systems design principle that provides for future growth.
Configurabilityπ£β«β«β«β«Systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
Portabilityπ£β«β«β«β«Portability in high-level computer programming is the usability of the same software in different environments.
Scalabilityπ£β«β«β«β«Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
Testabilityπ£π£β«β«β«Degree to which a software artifact (i.e. a software system, software module, requirements- or design document) supports testing in a given test context.
Feasibilityπ£π£π£π£π£For a software project to be feasible, it must be possible to complete the work in the time and/or budget dictated. For this reason feasibility touches on a number of other QARs, including time-to-market, total cost of ownership, technical knowledge, and migration requirements.
Deployabilityπ£β«β«β«β«Deployability is the degree of ease with which software can be taken from the development to the production environment.
Elasticityπ£β«β«β«β«The degree to which a system is able to adapt to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible.
Evolvabilityπ£β«β«β«β«Evolvability is the property of systems that can easily be updated to fulfill new requirements; software that is evolvable will cost less to maintain.
Fault toleranceπ£β«β«β«β«Fault tolerance is the property that enables a system to continue operating properly in the event of the failure of one or more faults within some of its components.
Integrabilityπ£β«β«β«β«Process of bringing together the component sub-systems into one system and ensuring that the subsystems function together as a system.
Interoperabilityπ£β«β«β«β«Interoperability is a characteristic of a product or system to work with other products or systems.
Performanceπ£π£π£β«β«The amount of useful work accomplished by a computer system.
Simplicityπ£π£π£π£π£Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. - Edsger W. Dijkstra (1984)
Workflowπ£β«β«β«β«The process of dividing software development work into smaller, parallel or sequential steps or subprocesses to improve design, product management.
π‘ Microkernel architecture
The microkernel architecture pattern (sometimes referred to as the plug-in architecture pattern) is a natural pattern for implementing product-based applications. A product-based application is one that is packaged and made available for download in versions as a typical third-party product. However, many companies also develop and release their internal business applications like software products, complete with versions, release notes, and pluggable features. These are also a natural fit for this pattern. The microkernel architecture pattern allows you to add additional application features as plug-ins to the core application, providing extensibility as well as feature separation and isolation. The microkernel architecture pattern consists of two types of architecture components: a core system and plug-in modules. Application logic is divided between independent plug-in modules and the basic core system, providing extensibility, flexibility, and isolation of application features and custom processing logic. The core system of the microkernel architecture pattern traditionally contains only the minimal functionality required to make the system operational. Many operating systems implement the microkernel architecture pattern, hence the origin of this patternβs name. From a business-application perspective, the core system is often defined as the general business logic sans custom code for special cases, special rules, or complex conditional processing.
Microkernel architecture graph Extensibilityπ£π£π£β«β«Software engineering and systems design principle that provides for future growth.
Configurabilityπ£π£π£π£β«Systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
Portabilityπ£π£π£β«β«Portability in high-level computer programming is the usability of the same software in different environments.
Scalabilityπ£β«β«β«β«Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
Testabilityπ£π£π£β«β«Degree to which a software artifact (i.e. a software system, software module, requirements- or design document) supports testing in a given test context.
Feasibilityπ£π£π£π£π£For a software project to be feasible, it must be possible to complete the work in the time and/or budget dictated. For this reason feasibility touches on a number of other QARs, including time-to-market, total cost of ownership, technical knowledge, and migration requirements.
Deployabilityπ£π£π£β«β«Deployability is the degree of ease with which software can be taken from the development to the production environment.
Elasticityπ£β«β«β«β«The degree to which a system is able to adapt to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible.
Evolvabilityπ£π£π£β«β«Evolvability is the property of systems that can easily be updated to fulfill new requirements; software that is evolvable will cost less to maintain.
Fault toleranceπ£β«β«β«β«Fault tolerance is the property that enables a system to continue operating properly in the event of the failure of one or more faults within some of its components.
Integrabilityπ£π£π£β«β«Process of bringing together the component sub-systems into one system and ensuring that the subsystems function together as a system.
Interoperabilityπ£π£π£β«β«Interoperability is a characteristic of a product or system to work with other products or systems.
Performanceπ£π£π£β«β«The amount of useful work accomplished by a computer system.
Simplicityπ£π£π£π£β«Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. - Edsger W. Dijkstra (1984)
Workflowπ£π£β«β«β«The process of dividing software development work into smaller, parallel or sequential steps or subprocesses to improve design, product management.
π± Microservices architecture
Microservices architecture (often shortened to microservices) refers to an architectural style for developing applications. Microservices allow a large application to be separated into smaller independent parts, with each part having its own realm of responsibility. To serve a single user request, a microservices-based application can call on many internal microservices to compose its response. A microservices architecture is a type of application architecture where the application is developed as a collection of services. It provides the framework to develop, deploy, and maintain microservices architecture diagrams and services independently. Within a microservices architecture, each microservice is a single service built to accommodate an application feature and handle discrete tasks. Each microservice communicates with other services through simple interfaces to solve business problems. Typically, microservices are used to speed up application development. Microservices architectures built using Java are common, especially Spring Boot ones. Itβs also common to compare microservices versus service-oriented architecture. Both have the same objective, which is to break up monolithic applications into smaller components, but they have different approaches.
Microservices architecture graph Extensibilityπ£π£π£π£π£Software engineering and systems design principle that provides for future growth.
Configurabilityπ£π£π£β«β«Systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
Portabilityπ£π£π£π£π£Portability in high-level computer programming is the usability of the same software in different environments.
Scalabilityπ£π£π£π£π£Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
Testabilityπ£π£π£π£π£Degree to which a software artifact (i.e. a software system, software module, requirements- or design document) supports testing in a given test context.
Feasibilityπ£β«β«β«β«For a software project to be feasible, it must be possible to complete the work in the time and/or budget dictated. For this reason feasibility touches on a number of other QARs, including time-to-market, total cost of ownership, technical knowledge, and migration requirements.
Deployabilityπ£π£π£π£π£Deployability is the degree of ease with which software can be taken from the development to the production environment.
Elasticityπ£π£π£π£π£The degree to which a system is able to adapt to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible.
Evolvabilityπ£π£π£π£π£Evolvability is the property of systems that can easily be updated to fulfill new requirements; software that is evolvable will cost less to maintain.
Fault toleranceπ£π£π£π£π£Fault tolerance is the property that enables a system to continue operating properly in the event of the failure of one or more faults within some of its components.
Integrabilityπ£π£π£β«β«Process of bringing together the component sub-systems into one system and ensuring that the subsystems function together as a system.
Interoperabilityπ£π£π£β«β«Interoperability is a characteristic of a product or system to work with other products or systems.
Performanceπ£π£β«β«β«The amount of useful work accomplished by a computer system.
Simplicityπ£β«β«β«β«Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. - Edsger W. Dijkstra (1984)
Workflowπ£β«β«β«β«The process of dividing software development work into smaller, parallel or sequential steps or subprocesses to improve design, product management.
π₯ Modular Monolith architecture
A monolithic architecture is the traditional unified model for the design of a software program. Monolithic, in this context, means composed all in one piece. Monolithic software is designed to be self-contained; components of the program are interconnected and interdependent rather than loosely coupled as is the case with modular software programs. A software system is called βmonolithicβ if it has a monolithic architecture, in which functionally distinguishable aspects (for example data input and output, data processing, error handling, and the user interface) are all interwoven, rather than containing architecturally separate components. To sum up, Monolith is nothing more than a system that has exactly one deployment unit. No less no more. Modular Monolith architecture is a explicit name for a Monolith system designed in a modular way. To achieve a high level of modularization each module must be independent, has everything necessary to provide desired functionality (separation by business area), encapsulated and have a well-defined interface/contract.
Modular Monolith architecture graph Extensibilityπ£π£β«β«β«Software engineering and systems design principle that provides for future growth.
Configurabilityπ£β«β«β«β«Systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
Portabilityπ£π£β«β«β«Portability in high-level computer programming is the usability of the same software in different environments.
Scalabilityπ£β«β«β«β«Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
Testabilityπ£π£β«β«β«Degree to which a software artifact (i.e. a software system, software module, requirements- or design document) supports testing in a given test context.
Feasibilityπ£π£π£π£π£For a software project to be feasible, it must be possible to complete the work in the time and/or budget dictated. For this reason feasibility touches on a number of other QARs, including time-to-market, total cost of ownership, technical knowledge, and migration requirements.
Deployabilityπ£π£β«β«β«Deployability is the degree of ease with which software can be taken from the development to the production environment.
Elasticityπ£β«β«β«β«The degree to which a system is able to adapt to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible.
Evolvabilityπ£β«β«β«β«Evolvability is the property of systems that can easily be updated to fulfill new requirements; software that is evolvable will cost less to maintain.
Fault toleranceπ£β«β«β«β«Fault tolerance is the property that enables a system to continue operating properly in the event of the failure of one or more faults within some of its components.
Integrabilityπ£β«β«β«β«Process of bringing together the component sub-systems into one system and ensuring that the subsystems function together as a system.
Interoperabilityπ£β«β«β«β«Interoperability is a characteristic of a product or system to work with other products or systems.
Performanceπ£π£π£β«β«The amount of useful work accomplished by a computer system.
Simplicityπ£π£π£π£π£Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. - Edsger W. Dijkstra (1984)
Workflowπ£β«β«β«β«The process of dividing software development work into smaller, parallel or sequential steps or subprocesses to improve design, product management.
π Service-Based architecture
Service-based architecture is a domain-partitioned architecture, meaning that the structure is driven by the domain rather than a technical consideration (such as presentation logic or persistence logic). Each service, being a separately deployed unit of software, is scoped to a specific domain. Changes made within this domain only impact the specific service, the corresponding user interface, and the corresponding database. Nothing else needs to be modified to support a specific assessment change (definition from Fundamentals of Software Architecture by Mark Richards and Neal Ford). Service-based architectures consist of tens of deployable services, rather than the hundreds or thousands advocated by microservice proponents. These services may have separate datastores, or may still share a single monolithic datastore.
Service-Based architecture graph Extensibilityπ£π£π£π£β«Software engineering and systems design principle that provides for future growth.
Configurabilityπ£π£β«β«β«Systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
Portabilityπ£π£π£π£β«Portability in high-level computer programming is the usability of the same software in different environments.
Scalabilityπ£π£π£β«β«Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
Testabilityπ£π£π£π£β«Degree to which a software artifact (i.e. a software system, software module, requirements- or design document) supports testing in a given test context.
Feasibilityπ£π£π£π£β«For a software project to be feasible, it must be possible to complete the work in the time and/or budget dictated. For this reason feasibility touches on a number of other QARs, including time-to-market, total cost of ownership, technical knowledge, and migration requirements.
Deployabilityπ£π£π£π£β«Deployability is the degree of ease with which software can be taken from the development to the production environment.
Elasticityπ£π£β«β«β«The degree to which a system is able to adapt to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible.
Evolvabilityπ£π£π£β«β«Evolvability is the property of systems that can easily be updated to fulfill new requirements; software that is evolvable will cost less to maintain.
Fault toleranceπ£π£π£π£β«Fault tolerance is the property that enables a system to continue operating properly in the event of the failure of one or more faults within some of its components.
Integrabilityπ£π£β«β«β«Process of bringing together the component sub-systems into one system and ensuring that the subsystems function together as a system.
Interoperabilityπ£π£β«β«β«Interoperability is a characteristic of a product or system to work with other products or systems.
Performanceπ£π£π£β«β«The amount of useful work accomplished by a computer system.
Simplicityπ£π£π£β«β«Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. - Edsger W. Dijkstra (1984)
Workflowπ£β«β«β«β«The process of dividing software development work into smaller, parallel or sequential steps or subprocesses to improve design, product management.
π Service-Oriented architecture
Service-Oriented Architecture (SOA) is a stage in the evolution of application development and/or integration. It defines a way to make software components reusable using the interfaces. Formally, SOA is an architectural approach in which applications make use of services available in the network. In this architecture, services are provided to form applications, through a network call over the internet. It uses common communication standards to speed up and streamline the service integrations in applications. Each service in SOA is a complete business function in itself. The services are published in such a way that it makes it easy for the developers to assemble their apps using those services. Note that SOA is different from microservice architecture. SOA allows users to combine a large number of facilities from existing services to form applications. SOA encompasses a set of design principles that structure system development and provide means for integrating components into a coherent and decentralized system. SOA-based computing packages functionalities into a set of interoperable services, which can be integrated into different software systems belonging to separate business domains.
Service-Oriented architecture graph Extensibilityπ£β«β«β«β«Software engineering and systems design principle that provides for future growth.
Configurabilityπ£β«β«β«β«Systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
Portabilityπ£β«β«β«β«Portability in high-level computer programming is the usability of the same software in different environments.
Scalabilityπ£π£π£β«β«Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
Testabilityπ£β«β«β«β«Degree to which a software artifact (i.e. a software system, software module, requirements- or design document) supports testing in a given test context.
Feasibilityπ£β«β«β«β«For a software project to be feasible, it must be possible to complete the work in the time and/or budget dictated. For this reason feasibility touches on a number of other QARs, including time-to-market, total cost of ownership, technical knowledge, and migration requirements.
Deployabilityπ£β«β«β«β«Deployability is the degree of ease with which software can be taken from the development to the production environment.
Elasticityπ£π£π£β«β«The degree to which a system is able to adapt to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible.
Evolvabilityπ£β«β«β«β«Evolvability is the property of systems that can easily be updated to fulfill new requirements; software that is evolvable will cost less to maintain.
Fault toleranceπ£π£π£β«β«Fault tolerance is the property that enables a system to continue operating properly in the event of the failure of one or more faults within some of its components.
Integrabilityπ£π£π£π£π£Process of bringing together the component sub-systems into one system and ensuring that the subsystems function together as a system.
Interoperabilityπ£π£π£π£π£Interoperability is a characteristic of a product or system to work with other products or systems.
Performanceπ£π£β«β«β«The amount of useful work accomplished by a computer system.
Simplicityπ£β«β«β«β«Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. - Edsger W. Dijkstra (1984)
Workflowπ£π£π£π£π£The process of dividing software development work into smaller, parallel or sequential steps or subprocesses to improve design, product management.