Disclaimer: While I usually reword several pieces of the content I take as notes from books like this one, many other pieces are just literal texts extracted from the book(s). The authors of those literal texts extracted from the books are the only owners of such content. If you're the co/author, publisher, or, in general, a copyright owner of this book or related material and consider the content of this website (https://lealceldeiro.com/) doesn't comply with your work's copyright policy, please get in touch .
Main notes taken from the book Building Event-Driven Microservices by Adam Bellemare.
Domain: The problem space that a business occupies and provides solutions to. This encompasses everything that the business must contend with, including rules, processes, ideas, business-specific terminology, and anything related to its problem space, regardless of whether or not the business concerns itself with it. The domain exists regardless of the existence of the business.
Domain (and subdomain) model: An abstraction of the actual domain useful for business purposes. The main domain model of ana business is discernible through the products the business provides its customers, the interfaces by which customers interact with the products, and the various other processes and functions by which the business fulfills its stated goals.
By keeping loose coupling between bounded contexts, and focusing on minimizing inter-context dependencies, we allow bounded context implementations to change as necessary, without subsequently breaking many (or any) other systems.
Teams that find it too hard to access data in their organization, or find their products are scope-creeping because all the data is located in a single implementation, are likely experiencing the effects of poor data communication structures. This problem will be magnified as the organization grows, develops new products, and increasingly needs to access commonly used domain data.
One of the tenets of event-driven microservices is that core business data should be easy to obtain and usable by any service that requires it. This replaces the ad hoc data communication structure in this scenario with a formalized data communication structure. Such a data communication structure could remove most of the difficulties of collecting data from other systems.
The event-driven data communication approach offers an alternative to the traditional behavior of implementation and data communication structures. It’s not a replacement, but rather a different solution to the tradition request-response approach used by many systems until now.
An event-streaming data communication structure decouples the production and ownership of data from the access to it.
In this paradigm, events are the basis of communication.
Some benefits of using event-driven microservices:
Granularity: Services map neatly to bounded contexts and can be easily rewritten when business requirements change.
Scalability: Individual services can be scaled up and down as needed.
Technological flexibility: Services use the most appropriate languages and technologies. This also allows for easy prototyping using pioneering technology.
Business requirement flexibility: Ownership of granular microservices is easy to reorganize. There are fewer cross-team dependencies compared to large services, and the organization can react more quickly to changes in business requirements.
Continuous delivery support: It’s easy to ship a small, modular microservice, and roll it back if needed.
High testability: Microservices tend to have fewer dependencies than large monoliths, making it easier to mock out the required testing endpoints and ensure proper code coverage.
An event-driven microservice is a small application built to fulfill a specific bounded context.
Consumer microservices consume and process events from one or more input event streams. Producer microservices produce events to event streams for other services to consume.
A microservice topology is the event-driven topology internal to a single microservice.
A business topology is the set of microservices, event streams, and APIs that fulfill complex business functions. Their grouping is arbitrary and can be owned by a single team or a department.
A microservice topology details the inner workings of a single microservice. A business topology details the relationships between multiple services.
Unkeyed event: used to describe an event as a singular statement of fact.
Entity event: a unique thing, keyed on the unique identifier of that thing. It describes the properties and the state of the entity at a given point in time.
Keyed event: contains a key but doesn’t represent an entity. They’re usually used to partition the stream of events to guarantee data locality within a single partition of an event stream.
Event data serves as the means of long-term and implementation agnostic data storage, as well as the communication mechanism between services.
Solutions such as Apache Avro and Google’s Protobuf, provide features such as an evolution framework
|
An evolution framework is the capability of performing certain sets of changes in a safe manner, without requiring downstream consumers to make any code change. |