O’Reilly Learning Course:
Architecture Styles vs. Patterns An Architecture Style is an overarching theme to the architecture. For example, microservices Architecture Style is a way of building services. However, you can use different Architecture Patterns to build your microservices such as Clean Architecture.
Responsibility is designing the structure of the application and its characteristics.
Architecture Characteristics – These are trade-offs you make when embracing an architecture style. For example, Microservices are independent slices of functionality that are highly scalable. However, they come at a cost of deployment complexity, cost, and a long time to market.
Very often Architecture Characteristics interfere with each other.
Elasticity is the ability to support a burst of users. For example, a concert ticketing site when they start accepting ticket purchases.
One of the keys in architecture design is iterative architecture design. You are never going to get it right up front.
Silverbullets don’t exist, as an architect, it’s you job to assess the problem space and discover the trade offs and present them to the business.
Defining Architecture Characteristics
- Has a non-domain design consideration
- Influences some structural aspect of the design
- Critical or important to application success
- Implicit (things architectures should have, but aren’t written down)
- Maintainability (good internal design)
The first law of the Software Architecture is everything is a trade-off.
Organize Applications by technical partitioning
The Value of Asynchronicity
Synchronous calls between microservices couples the microservices and can also impact performance. In essence you’ve got a blocking thread with synchronous calls. If one microservice needs another microservice to perform work, use message queues to decouple the dependencies.
If I’m waiting on the response it’s synchronous.
Neal feels architects get too involved in implementation details. All architects should be concerned with is whether it’s asynchronous or synchronous.
The Role of an Architect
Your role as an architect is governance. You police the implementation of the architecture.
To ensure the architecture is followed, you need to implement an architecture fitness function. An architecture fitness function checks conditions are not violated. Such as software requests crossing boundaries that they were not intended to cross. A library in the Java would to enforce architecture rules is called "Arch Unit." In the .Net world it’s called "NetArchTest".
When a company wants you to use a special custom code generation tool ask:
- Can I version it in version control?
- Can I diff it to see the difference between two different workflows?
- Can I evolve it over time without duplication, are there abstractions?
- Is there a sophisticated IDE with refactoring support and code insight?
How to you share data:
- Make it one big component
- Duplicate the data
- Couple the services
Pick the option with the least amount of trade-offs.
Is an architecture that uses a plug-in architect.
Core System – minimal functionality to run system general business rules and logic no custom processing
Plug-in module – standalone independent module specific additional rules or logic.
You can use the Strategy pattern to implement Microkernel Architecture, but it’s more akin to the Template pattern.
The plug-in’s must not communicate to each other!!! You go down a rabbit hole of pain. OSGI of Eclipse is an example of this.
Events and messages can be used as a communication medium in other architectures.
It’s rare to find both Performance and Scaleability in an architecture topology.
An event happens and a message is dropped in a queue. For example, someone has moved and a change address event is posted to a queue. Once the change of address is completed a new message is posted to the completed change address queue. The quote process sees the address change and then picks up the message and processes the message….
Each time something changes, a message is posted to a queue notifying it’s completed and the concerned parties process the messages.
This is a loosely coupled architecture, but the downside is there is no coordinator to manage system concerns such as errors.
Broker architecture is an extremely decoupled architecture.
This is every similar to the Broker Topology, but it has a mediator. The mediator manages all event messages. Including events between event processors. Event processors DO NOT directly communication with each other.
This is a great example of orchestration. A single point manages the flow of the data through a workflow and ensures it’s completed. Think of a mediator as a conductor of a music.
Change this architecture is harder because there are more moving parts.
Domain Architecture Isomorphism
Reuse is coupling. Which is a very brittle architecture, everything is coupled…
"It’s either coupling or duplication, that’s the tradeoff." – Eric Evans
Everything is technically partitioned, which means the domain is grounded up and spread all over the place. To change a feature means you have to look throughout the application to find parts of the feature.
In contrast, if you look at Microservices, its domain/feature partitioned, so all the domain is one area of the application. This makes changes to functionality much easier.
Last 10% Trap
Everything Access Project started as a booming success, but then would end in failure.
About 80% of what user want in Access is super fast and easy to implement. The next 10% is possible, but it’s hard to accomplish. The last 10% is impossible because you don’t have the integration points.
"Users always want 100% of what they want (and are never satisfied with less)
Data Fitness Functions
Consumer Driven Contracts
Benefit is scalability
It’s weakness is performance.
This architecture can either come from a Modular Monolith which has been decomposed into separate services but still maintain a shared database. Or Microservices bundled back together into a single database. While Microservices is has great scalability, it typically has poor performance because of all the network communication and serialization and de-serialization of JSON.
At a high level Service-based Architecture is large microservices (more than one bounded context per service) and one or more shared data source. Typically, there is one or a few shared databases.
Orchestration vs. Choreography
These best orchestration in Microservices is no orchestration. Fix your granularity instead. Most of the time, when you need a transaction across service boundaries you’ve gotten your granularity wrong.
If you need to get information from two different services, create an orchestrator service (aka a Mediator) to interact with those two different services.
Choreography is following a plan or workflow. A lot of the times, synchronous calls are required.