The hardest part of microservices is your data.
Hear from Christian Posta, Principal Architect, Red Hat, in this breakout session at Red Hat Summit 2017.
One of the tenants of microservices, and a way to minimize dependencies, is that “a service should own its database.” This is easier said than done. Why? Because: your data. In working with data in information systems for five decades, application developers have accepted using relational databases and relying on their safety guarantees. But, as we build service architectures that span more than one database by design (as with microservices), things get more challenging. How do we synchronize data across databases, exceptionally heterogeneous data? Developing for the traditional enterprise, we must build fast-changing systems surrounded by legacy systems with complicated domains like finance, insurance, and retail. So, how do we develop and reason about the boundaries in our approach to reducing complexity in the field?
In this session, we’ll explore these problems and see how domain-driven design (DDD) helps grapple with domain complexity. We’ll see how DDD concepts like entities and aggregates help us understand boundaries—based on use cases and how transactions are affected. With transactional limits, we can more carefully adjust our needs from the CAP theorem to scale and achieve autonomous systems with eventual strictly ordered consistency. We’ll see how technologies like Apache Kafka, Apache Camel, and Debezium.io can help build the backbone for these systems. And finally, we’ll look at a working example that brings all this together.
Domain Driven Design (DDD)
Domain-Driven Design (DDD) is a software development approach that defines and solves complex business problems by modeling the underlying business domain. It emphasizes a deep understanding of the problem domain and aligning software design with business goals.
DDD involves modeling the domain through concepts such as entities, value objects, aggregates, and services and using those models to drive the design of the software. DDD aims to create software that is expressive of the underlying domain and can evolve and grow along with the business needs.
Yes, Domain-Driven Design can be used for microservices architecture. Microservices is an approach to software development where an extensive application is broken down into smaller, independent, and loosely coupled services. DDD can help design these services by providing a way to model the business domain and align the design of the services with the business goals. Using DDD, each microservice can be designed around a specific bounded context, which helps to manage the system’s complexity and ensure that each service is focused on solving a particular problem.
Microservices
Microservices is an architectural style for building applications as a collection of small, independent, and loosely-coupled services. Each service is responsible for a specific business capability and can be developed, deployed, and managed independently from the other services. This allows for greater flexibility, scalability, and faster development and deployment times.
In a microservices architecture, services communicate with each other over a network, usually using APIs. Services can be written in different programming languages and run on different operating systems, allowing for a heterogeneous technology stack.
Microservices architecture is often used in modern, cloud-based applications and is especially well-suited for complex and large-scale applications requiring high agility and scalability. Microservices can also help reduce the risk of downtime, as failures in one service can be isolated and do not affect the other services.