Table of Contents

• Component Diagram {Development View)
• Deployment Diagram (Physical View)
• Architectural Decision Record (ADR)
  • Context
  • Decisions
  • Consequences
  • Considered Alternatives

Component Diagram (Development View)

Deployment Diagram (Physical View)

Architectural Decision Record (ADR)

Title: Selection of Three-Tiered Layered Style with Service-Oriented (SOA) and Publish/Subscribe (Pub/Sub) Architectural Styles for the Logic Layer

Status: Accepted

Date: 2023.11.12

Context

The Dentago project aims to create a distributed system that connects dentists with patients, facilitating the process of booking and managing appointments. The primary architectural goal is to achieve high scalability and performance, as the system is intended to scale to serve a mass market across the whole country.

Decisions

1. System > Layered Style (Three-Tier [presentation, logic, data layers]): We have chosen the Layered Three-Tier architecture pattern to introduce separation of concerns in our system between our presentation, business logic and data access layers. This is a hallmark decision to increase scalability, as it introduces layer modularity and allows easier demand handling through various techniques. It also improves the ease to develop and test, as well as to modify and extend.

2. Logic Layer > Service-Oriented Architecture (SOA): We have chosen the SOA architectural pattern to have loose coupling between the different business logic services, and thus enable a more scalable approach. We also benefit from being able to use different technologies and programming languages in different services, and we are also more capable of aligning our architecture to the nature of the business (which naturally keeps it more understandable and manageable).

3. Logic Layer > Publish/Subscribe (Pub/Sub): We have chosen the Publish/Subscribe architectural pattern to facilitate communication between system service components. Pub/Sub provides efficient real-time asynchronous communication and promotes scalability. It also decouples the different components, making it easier to modify each or add new ones.

Consequences

• Maintainability & Testability: The Layered Style with a Three-Tier Architecture clearly defines a separation between the presentation, logic and data layers. The modularity of the system makes each layer easier to develop and test independently, as well as to modify and extend in the future. SOA further allows for this modularization, by decomposing the business logic into independent services. However, it may become more complex to initially set the modules up in an effective manner.

• Availability: SOA and Pub/Sub contribute positively to system availability by allowing dynamic reconfiguration without system interruption (SOA) and by providing decoupling between different service components (Pub/Sub).

• Scalability: The Layered Style with a Three-Tier Architecture allows for a much easier scaling of each of the layers independently. It enables the developer team to handle increasing traffic without having to impact the whole system (e.g., the team can introduce horizontal or vertical scaling to a layer, caching, database partitioning, etc.). SOA further affirms a loose coupling approach, to the same effect. Pub/Sub supports horizontal scalability, allowing for efficient handling of an increased number of communications (but potentially introducing performance bottlenecks if not managed properly).

• Modifiability & Extendibility: SOA's flexibility and the decoupling offered by Pub/Sub both enhance modifiability and extendibility of the system.

• Performance: Pub/Sub can lead to performance issues if the message broker becomes overloaded, potentially negatively impacting scalability unless mitigated.

• Reusability: The Layered Style with a Three-Tier Architecture allows components within each of the layers to be reused across different applications, which in some cases can help diminish the effort and time dispensed in the development. SOA leverages this, because individual services can be reused across different applications.

Considered Alternatives

• Microservices pattern: Microservices introduce complexity and resource overhead that is needless for our use case. The network dependencies in microservices can negatively impact both performance, which is an important consideration for our system.

• Pipe-Filter pattern: Pipe-Filter is not suitable for our system as it primarily serves data transformation purposes and is not well-suited for interactive systems. It also has weaknesses in terms of performance.

• Monolithic pattern: This pattern would have made it easier to develop, at least at an early stage, but it would ultimately falter in terms of scalability - which is one of the main priorities for our system. It would also be lackluster in respects to maintainability and reusability.