Microservice (part2)
It’s better to have read part1 before starting this section.
in this part, we learn how to decompose an application into services.
Traditionally, the goal of architecture has been scalability, reliability, and security. But today it’s important that the architecture also enables the rapid and safe delivery of software. You’ll learn that microservice architecture is an architecture style that gives an application high maintainability, testability, and deployability.
The software architecture of a computing system is the set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both.
4+1 view model
defines four different views of software architecture. Each describes a particular aspect of the architecture and consists of a particular set of software elements and relationships between them.
Logical view: the software elements like classes, packages … and relationships between them.
Implementation view: The output of the build system. This view consists of modules, which represent packaged code, and components, which are executable. in Python Simply, a module is a file consisting of Python code. A module can define functions, classes, and variables. A module can also include runnable code.
Process view: The components at runtime. Each element is a process and the
relations between processes represent interprocess communication.
Deployment: How the processes are mapped to machines.
we can implement the functional requirements of our application without any accurate architecture but if it comes to quality of service requirements, which are the so-called _lities such as scalability and reliability, maintainability, testability, and deployability we should determine well architecture.
three-tier architecture
this architecture organizes the application’s classes into the following tiers or layers Each layer has a well-defined set of
responsibilities:
Presentation layer — contains code that implements the user interface or external APIs
Business logic layer — Contains the business logic
Persistence layer — Implements the logic of interacting with the database
This architecture has some drawbacks for example it doesn't represent in fact that an application is likely to be involved by more than just a single system or interact with more than just a single database.
HEXAGONAL ARCHITECTURE
hexagonal architecture is an alternative to the layered architectural style. This architecture places business logic at the center and has one or more inbound adapters and outbound adapters that are invoked by the business logic.
The business logic has one or more ports. A port defines a set of operations and is how the business logic interacts with what’s outside of it. it can be interface or abstract class in Python.
An inbound adapter handles requests from the outside world by invoking an inbound port. like message consumer.
An outbound adapter implements an outbound port(interface) and handles requests from the business logic by invoking an external application or service. like message producer or data access object(DOA)
Multiple inbound adapters can invoke the same inbound port like “message consumer” and “some controller class” in above picture.
Business logic doesn’t depend on either the presentation logic or the data access logic.
microservice architecture
Microservice architecture is also an architectural style. It structures the implementation view as a set of multiple components: executables or WAR files. The components are services, and the connectors are the communication protocols that enable those services to collaborate.
what it means to be loosely coupled
A service has an API that provides its clients access to its functionality. There are two types of operations: commands and queries. The API consists of commands, queries, and events.
service consists of commands which perform actions and update data and query to retrieve data and events that are consumed by its clients.
Unlike in a monolith, a developer can’t write code that bypasses its API.
Each service in a microservice architecture has its own architecture and, potentially, technology stack. But a typical service has a hexagonal architecture.
loosly coupled service means that all interaction with a service happens via its API. this enables the implementation of the service to change without impacting its clients.
You must treat a service’s persistent data like the fields of a class and keep them private. Keeping the data private enables a developer to change their service’s database schema without having to spend time coordinating with developers working on other services.
You should strive to use libraries for functionality that’s unlikely to change. For example, in a typical application it makes no sense for every service to implement a generic Money class. Instead, you should create a library that’s used by the services. otherwise you should implement that functionality that's likely to change as a service.
in microservice it doesn't matter what size of your service is because in reality size isn't a useful metric.A much better goal is to define a well-designed service to be a service capable of being developed by a small team with minimal lead time and with minimal collaboration with other teams.
a team might only be responsible for a single service, so that service is by no means micro.if a service requires a large team or takes a long time to test, it probably makes sense to split the team and the service. Or if you constantly need to change a service because of changes to other services or if it’s triggering changes in other services, that’s a sign that it’s not loosely coupled.
