Software Architecture

  • Software Architecture is the process that takes place before any implementation where the basic architecture of the software takes place.
  • The software architecture of a system represents the design decisions related to overall system structure and behavior.
  • FreeCodeCamp -The Software Architecture Handbook
  • Implementation details (that is, the folder structure of your repo)
  • Implementation design decisions (Do you use server side or client side rendering? Relational or non-relational databases?)
  • The technologies you choose (Do you use REST or GraphQl for your API? Python with Django or Node with Express for your back end?)
  • System design decisions (like is your system a monolith or is it divided into microservices?) Infrastructure decisions (Do you host your software on premise or on a cloud provider?)
  • Wichtige Konzepte

  • Client-Server Model

  • Splits workload between ressource or service provider (server) and a service or resource requester (client)
  • API

  • application programming interface
  • interface that is used for the communication between client and server
  • a set of rules that defines which client request will trigger which server response
  • Modularity

  • It’s good for dividing concerns and features, which helps with the visualization, understanding, and organization of a project.
  • The project tends to be easier to maintain and less prone to errors and bugs when it’s clearly organized and subdivided.
  • If your project is subdivided into many different pieces, each can be worked on and modified separately and independently, which is often very useful.
  • Software Architecture Patterns

  • Monolithic Architecture

  • Example: Our app is a web streaming platform Notflix for films.
  • It has the following functions:
    • Authentication
    • Payment
    • Streaming
  • Clients:
    • Web Client
    • Mobile Client
    • Tv Client

  • The main benefit of a monolithic design is its simplicity. The functioning of it and the set up required is simple and easy to follow, and this is why most applications start out in this way.
  • vertical scaling: get more CPU and RAM for your monolithic server. At some point it wont scale any more!
  • complexity: the more features you build, the more complex your codebase becomes
  • Microservice Architecture

    ![Microservice Architecture](file:///C:/Users/dka/OneDrive - dotSource GmbH/Dokumente/Notes/learning/learning/cs/../../media/qownnotes-media-NShNnw.png)
  • You can scale particular services as needed, instead of scaling the whole back end at once. Following our example, when we started to experience performance issues we vertically scaled our whole server – but actually the feature that requested the more resources was only the streaming. Now that we have the streaming feature separated into a single server, we can scale only that one and leave the rest alone as long as they keep working right.
  • Features will be more loosely coupled, which means we’ll be able to develop and deploy them independently.
  • The codebase for each server will be much smaller and simpler. Which is nice for the dev folks that have been working with us from the start, and also easier and quicker for new developers to understand.

  • Backend for front-end (BFF)

  • horizontal scaling: Setting up more servers for a service. This distribution of requests is normally performed by a thing called a load balancer. Load balancers act as reverse proxys to our servers, intercepting client requests before they get to the server and redirecting that request to the corresponding server.
  • Source-replica model for databases

  • One way of implementing this is with a source-replica model, in which one particular source DB will receive all write queries and replicate it’s data along one or more replica DBs. Replica DBs will receive and respond to all read queries.
  • The advantages of DB replication are:
  • Better performance: This model improves performance allows more queries to be processed in parallel.
  • Reliability and availability: If one of your database servers is destroyed or inaccessible for any reason, data is still preserved in other DBs.
  • Where the architecture you choose lifes

  • On Premise

  • You own the hardware where the application lives on.
  • Traditional Server Providers

  • You rent a server and the company running the servers is responsible for all hardware issues.
  • Cloud

  • Big companys own big data centers and sell the usage of their computing power to others. AWS, Azure, Google Cloud etc.
  • Different ways of using it:
  • Traditional: You just use then like traditional server providers.
  • Elastic: hardware capacity of your app will grow or shrink depending on usage
  • Serverless: individual functions mapped to an access point, these functions perform everytime they are requested, there is no server that bundles all functions.
  • Folder structures

  • Layered structure

  • Application layer structure
  • The application layer will have the basic setup of our server and the connection to our routes (the next layer).
  • The routes layer will have the definition of all of our routes and the connection to the controllers (the next layer).
  • The controllers layer will have the actual logic we want to perform in each of our endpoints and the connection to the model layer (the next layer, you get the idea…)
  • The model layer will hold the logic for interacting with our mock database.
  • Finally, the persistence layer is where our database will be.
  • Layered application structure
  • is shown in in the folder structure
  • Model View Controller (MVC)

  • MVC Model
  • The view layer will be responsible for rendering the UI.
  • The controllers layer will be responsible for defining routes and the logic for each of them.
  • The model layer will be responsible for interacting with our database.

  • SA might not be what you think

  • Software Architecture might not be what you think
  • Software architecture needs to be wrested from committees of people disconnected from developing, and to put it in the hands of the people who can actually make it real and executable, the developers. Only then will we achieve the resilience and sustainability that we need from today’s applications Software architecture is about capturing decisions, not describing structure
  • Architecting is a skill that agile teams embody, which means that Architect should not be a role
  • Architecting means continuously exploring new approaches and different alternatives to best meet quality attributes
  • The key activity of architecting is forming hypotheses about how the system will meet quality attribute goals, and then using empiricism to test whether the system meets them, and then repeating this loop until the system meets its quality goals

References: Computer Science Software Development