“Ninety-five percent of the words are spent extolling the benefits of ‘modularity’ and that little, if anything, is said about how to achieve it”—Glenford J. Myers, 1978.
The above quote is 40 years old. Today, four decades later, nothing has changed except terminology. Time to fix this.
Vladik Khononov explains how to decompose a system into loosely coupled components: how to draw boundaries between services, how to decide whether some logic belongs to one service or another, and how domain-driven design can help us make those decisions. Finally, he takes a stab at answering the age-old question of what part of a microservice should be “micro” and how it can be measured.
You’ll hear about neither Docker nor Kubernetes. Actually, nothing related to infrastructure. Instead, you’ll dive into the difference between microservices and bounded contexts, discover when each pattern should be used, and get takeaways from Vladik’s experience optimizing microservices-quotebased architectures at Naxex.
Vladik (Vlad) Khononov is a software engineer with over 15 years of industry experience at companies large and small, in roles ranging from webmaster to chief architect. A longtime proponent of domain-driven design and evolutionary architecture, Vlad helps companies make sense of their business domains, untangle monoliths, and tackle complex architectural challenges. He maintains an active media career as a public speaker and blogger and has spoken at numerous industry conferences — including O’Reilly Software Architecture, DDD Europe, and NDC — about subjects such as domain-driven design, microservices, and software architecture in general. In addition to his media work, he co-organizes the Domain-Driven Design Israel and Tel Aviv Software Architecture meetup groups. He lives in Northern Israel with his wife and an almost-reasonable number of cats.
Comments on this page are now closed.
©2019, O'Reilly Media, Inc. • (800) 889-8969 or (707) 827-7019 • Monday-Friday 7:30am-5pm PT • All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners. • firstname.lastname@example.org