To create a microservice architecture for an application, you’ll need to identify services, their interfaces, and how they interact. Although written well before microservices became popular, Eric Evans’ book, Domain-Driven Design (Addison-Wesley Professional), has proven to be a useful reference.
One of the key principles that Evans articulates is beginning with a domain model and identifying bounded contexts. This process has become a widely recommended approach for identifying microservices. For Cassandra, the recommended method for data modeling is to use a query-driven approach to identify tables.
For example, after identifying the key entities in a domain by creating a conceptual data model, you can analyze the anticipated workflows of the application to identify how the entities will be read by the application. The resulting queries are used to identify the tables that will be created, which can be documented in logical and physical data models.
The resulting queries are used to identify the tables that will be created, which can be documented in logical and physical data models. You can see an example of how this process works in Chapter 5 of Cassandra: The Definitive Guide, which is freely available as part of the Cassandra project documentation.
To define a microservice architecture, use a process that complements these data modeling processes. As you begin to identify entities as part of a conceptual data modeling phase, you can identify bounded contexts that represent groupings of related entities.
As you progress into logical data modeling, you refine the bounded contexts to identify specific services that will be responsible for each table (or group of related, denormalized tables). During the final stage of the design process, you confirm the design of each service, database selection, physical data models, and actual database schema.
This is a preview of the Designing Microservices With Cassandra Refcard. To read the entire Refcard, please download the PDF from the link above.