Book Software Architecture Practice Brief - leqviet/wikidls GitHub Wiki
https://medium.com/educative/software-architecture-diagramming-and-patterns-7d38999e7a12
What are these early design decisions embodied by software architecture? Consider:
- Will the system run on one processor or be distributed across multiple processors?
- Will the software be layered? If so, how many layers will there be? What will each one do?
- Will components communicate synchronously or asynchronously? Will they interact by transferring control or data or both?
- Will the system depend on specific features of the operating system or hardware?
- Will the information that flows through the system be encrypted or not?
- What operating system will we use?
- What communication protocol will we choose?
Another book Software Architecture Hard Park : One distinguishing factor about the shared service technique is that the shared code must be in the form of composition, not inheritance. While there is a lot of debate about the use of composition over inheritance from a source code design standpoint (see the Thoughtworks article “Composition vs. Inheritance: How to Choose” and Martin Fowler’s article “Designed Inheritance”), architecturally composition versus inheritance matters when choosing a code-reuse technique, particularly with the shared services technique.
Figure 2-13. The dimensions of dynamic quantum coupling
Step to follow break the monolithic application to microservice
- identify the size component pattern
- gather domain component pattern
- flattern component pattern
- determine component dependency pattern
- create component domain pattern
- create domain service pattern
The Hexagonal pattern separated domain logic from technical coupling
Figure 8-15. A service mesh is an operational link among services
Figure 9-3. Common ownership uses a dedicated service owner
Instead of ACID, distributed transactions support something called BASE. In chemistry, an acid substance and a base substance are exactly the opposite. The same is true with atomic and distributed transactions—ACID transactions are opposite of BASE transactions. BASE describes the properties of a distributed transaction: basic availability, soft state, and eventual consistency.
Basic availability (the “BA” part of BASE) means that all of the services or systems in the distributed transaction are expected to be available to participate in the distributed transaction. While asynchronous communication can help decouple services and address availability issues associated with the distributed transaction participants, it unfortunately impacts how long it will take the data to become consistent for the atomic business transaction (see eventual consistency later in this section).
Soft state (the S part of BASE) describes the situation where a distributed transaction is in progress and the state of the atomic business request is not yet complete (or in some cases not even known). In the customer registration example shown in Figure 9-12, soft state occurs when the customer profile information is inserted (and committed) in the Profile table, but the support contract and billing information are not. The unknown part of soft state can occur if, using the same example, all three services work in parallel to insert their corresponding data—the exact state of the atomic business request is not known at any point in time until all three services report back that the data has been successfully processed. In the case of a workflow using asynchronous communication (see Chapter 11), the in-progress or final state of the distributed transaction is usually difficult to determine.
Eventual consistency (the E part of BASE) means that given enough time, all parts of the distributed transaction will complete successfully and all of the data is in sync with one another. The type of eventual consistency pattern used and the way errors are handled dictates how long it will take for all of the data sources involved in the distributed transaction to become consistent.
The next section describes the three types of eventual consistency patterns and the corresponding trade-offs associated with each pattern.
Orchestrated Request-Based Pattern
Figure 9-18. A dedicated orchestration service takes on the role of an orchestrator for the distributed transaction
Orchestrator Service must now decide what action to take while the customer is waiting for the request to be processed:
Should the orchestrator send the request again to the Billing Payment Service for another try?
Should the orchestrator perform a compensating transaction and have the Support Contract and Customer Profile Services reverse their update operations?
Should the orchestrator respond to the customer that an error occurred and to wait a bit before trying again, while trying to repair the inconsistency?
Should the orchestrator ignore the error in hopes that some other process will deal with the issue and respond to the customer that they have been successfully unsubscribed?
Event-Based Pattern
Figure 9-20. The event-based pattern uses asynchronous publish-and-subscribe messaging or event streams to achieve eventual consistency
For implementations using standard topic-based publish-and-subscribe messaging (such as ActiveMQ, RabbitMQ, AmazonMQ, and so on), services responding to the event must be set up as durable subscribers to ensure no messages are lost if the message broker or the service receiving the message fails. A durable subscriber is similar in concept to persistent queues in that the subscriber (in this case, the Support Contract Service and Billing Payment Service) does not need to be available at the time the message is published, and subscribers are guaranteed to receive the message once they become available. In the case of event streaming implementations, the message broker (such as Apache Kafka) must always persist the message and make sure it is available in the topic for a reasonable amount of time.
