The Software Architects' Newsletter February 2020

A monthly overview of things you need to know as an architect or aspiring architect. [InfoQ]( The Software Architects' Newsletter February 2020 [View in browser]( Our thirty-first issue of the Architects’ Newsletter again focuses on the connected topics of architecture styles and governance strategies. The goal is to provide insight into how organizations are choosing effective architecture styles, whether this is based on functions, (micro)services, or a monolith, and also to explore the related issues of governance and compliance. We believe these topics are vitally important. They are visible at every stage of adoption in our latest [Architecture and Design InfoQ Trends Report](, from microservices and event-driven architecture to the concept of "the architect as a technical leader". News Modular Monolithic Architecture, Microservices, and Architectural Drivers From observing what is currently happening within the software development community, [Kamil Grzybek]( concludes in a recent article that most new projects are [implemented using the microservices architecture](. He believes that the IT industry at large is making a mistake adopting microservices just because they believe this will solve all of the problems with monolithic applications. Instead, Grzybek recommends we focus on [architectural drivers](, and emphasizes that every architecture has its pros and cons — it will solve some problems but also create new problems. In a series of articles, he describes the [basic concepts and properties of a modular monolith]( and the [drivers leading to a specific architecture](. Service Mesh Ultimate Guide: Managing Service-to-Service Communications in the Era of Microservices The arrival of the [service mesh]( technology has largely been due to a perfect storm within the IT landscape. Platform teams began embracing container orchestration systems like [Kubernetes]( and wanted to dynamically route traffic in and around the system using modern API-driven network proxies, such as [Envoy](. Developers began building distributed systems using a multi-language (polyglot) approach and needed dynamic service discovery. Operations began using ephemeral infrastructure, and wanted to gracefully handle the inevitable communication failures and enforce network policies and governance. This article aims to answer pertinent questions for software architects and technical leaders, such as: what is a service mesh?, do I need a service mesh?, and how do I evaluate the different service mesh offerings? Dissecting Bounded Contexts: Nick Tune at DDD Europe In software, there are many reasons for breaking up systems and [making them more modular](, [Nick Tune]( notes in his keynote at the recent [DDD Europe 2020]( conference in Amsterdam. We lower the cognitive load when we can look at a part of a large system. Teams can work autonomously and independently on different parts. From a business perspective, we can do more granular investments and spend more of our resources on more important parts. In his presentation, Tune discusses modularity and how by [dissecting and analyzing bounded contexts](, we can find more modeling options when designing and evolving them. Event Sourcing Done Right — Experience from the Trenches: Dennis Doomen at DDD Europe Event sourcing is just a tool; it’s [not a top-level architecture style]( and should not be used everywhere. This is what [Dennis Doomen]( points out in his presentation given on the [Event Sourcing day]( at the recent [DDD Europe 2020]( conference in Amsterdam, where he shared some of the practices he has found useful when [applying event sourcing]( on a problem. Doomen claims that one consequence of using event sourcing is you must understand the domain you are working in — this is a good thing. In his experience, too many systems are built without a proper understanding of the business perspective. Q&A on the Book Righting Software [Righting Software](, by Juval Löwy, provides a [structured way to design a software system]( and the project to build it. Löwy explains why the common way of designing the system against the requirements cannot work and instead proposes to use volatility-based decomposition to encapsulate changes inside the system’s building blocks. Following the system design, Löwy explains how to design the project in order to provide decision-makers with several viable options trading schedule, cost, and risk. The book offers case studies, guidelines and directives, and advice on how to present the design and earn the trust and respect of management. The Distributed Data Mesh as a Solution to Centralized Data Monoliths Instead of building large, centralized data platforms, enterprise data architects should create [distributed data meshes](. Such a change in approach requires a paradigm shift, according to [Zhamak Dehghani](, principal technology consultant at ThoughtWorks, who shared her ideas in a presentation at QCon San Francisco and a [related article](. As data becomes ever more ubiquitous, traditional architectures of data warehouses and data lakes become overwhelmed and are unable to scale efficiently. Dehghani argues that a distributed data mesh approach can overcome these inherent inefficiencies by embracing domain-oriented data ownership. Privacy Architecture for Data-Driven Innovation In this recent InfoQ article, [Nishant Bhajaria]( argues that by the time you start a [privacy program](, you have already collected a lot of data and possibly even made some privacy mistakes. Modern data-powered businesses operate on a bottom-up model while privacy needs some level of centralized top-down guidance and consistency. A data-driven privacy architecture includes data governance for data you collect, and data sharing models that use anonymization and other privacy-centric techniques. You want tools that categorize data based on risk and apply techniques to protect data based on risk levels. For privacy, you need to think of “data sharing” anytime data leaves your domain. Case Study Balancing Coupling in Distributed Systems: Vladik Khononov at DDD Europe We have been told that coupling is bad, so we decouple everything and break everything apart into tiny services or functions so each service can be changed independently. But by following this reasoning we often end up with a [distributed monolith](, [Vladik Khononov]( noted in his presentation at the recent [DDD Europe 2020]( conference in Amsterdam. Instead of fighting coupling, he [proposes that we use it as a design tool](, as a heuristic for improving system design. Khononov, cloud architect at [DoiT International](, refers to [Michael Nygard]( who has defined coupling as the relationship between components and these components’ degree of freedom. Khononov notes that this may seem limiting, but to make changes safe we want these limits; they are part of the design and the problem we are solving in our system. He also points out that there are relations between components in all systems, otherwise it’s not a system, just a number of unrelated independent entities. To design systems, we therefore need to design the relations and treat them as an inherent part of system design. There are various degrees of coupling and they can be observed in three dimensions: strength, distance, and volatility. The combination of these three properties defines the coupling’s overall effect on a system. Khononov summarizes by noting that the interplay between the three dimensions that describe the nature of relationships between two components affects how hard it will be to maintain that relationship. To minimize, we must eliminate accidental coupling, reduce connascence as much as possible, mitigate volatility with integration-specific interfaces, and reduce distance. This is an excerpt from the InfoQ article "[Balancing Coupling in Distributed Systems](." For a quick introduction to Domain Driven Design, download InfoQ’s [free eBook](. To get notifications when InfoQ publishes content on these topics follow To get notifications when InfoQ publishes content on these topics, follow "[architecture](", "[microservices](", "[governance](" and "[compliance](" on InfoQ. Missed a newsletter? You can find all of the [previous issues]( on InfoQ. InfoQ strives to facilitate the spread of knowledge and innovation within this space, and in this newsletter we aim to curate and summarise key learnings from news items, articles and presentations created by industry peers, both on InfoQ and across the web. We aim to keep readers informed and educated about emerging trends, peer-validated early adoption of technologies, and architectural best practices, and are always keen to receive feedback from our readers. We hope you find it useful, but if not you can unsubscribe using the link below. [Unsubscribe]( Forwarded email? Subscribe and get your own copy. [Subscribe]( Follow InfoQ.com on [Twitter]( [Facebook]( [LinkedIn]( [Youtube]( You have received this email because you subscribed to "The Architects' Newsletter". To stop receiving the Architects' Newsletter, please click the following link: [Unsubscribe]( - - - C4Media Inc. (InfoQ.com), 2275 Lake Shore Boulevard West, Suite #325, Toronto, Ontario, Canada, M8V 3Y3