From febd86dec8b81c80366e1dfd59b1fc6e02d18cf4 Mon Sep 17 00:00:00 2001 From: Michael K Date: Tue, 10 Oct 2023 09:30:11 -0400 Subject: [PATCH] change 'is' to 'are' for plural subjects. --- chapters/architecture.bd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chapters/architecture.bd b/chapters/architecture.bd index 7127f43..8a03504 100644 --- a/chapters/architecture.bd +++ b/chapters/architecture.bd @@ -20,7 +20,7 @@ One fundamental unit of which an architecture is composed is a *component*. This The second fundamental unit of architecture is *connectors*. Connectors are code that transmit information _between_ components. They're brokers that connect components, but do not necessarily have meaningful behaviors or states of their own. Connectors can be things like function calls, web service API calls, events, requests, and so on. None of these mechanisms store state or functionality themselves; instead, they are the things that tie components functionality and state together. -Even with carefully selected architectures, systems can still be difficult to put together, leading to *architectural mismatch*. When mismatch occurs, connecting two styles can require dramatic amounts of code to connect, imposing significant risk of defects and cost of maintenance. One common example of mismatches occurs with the ubiquitous use of database schemas with client/server web-applications. A single change in a database schema can often result in dramatic changes in an application, as every line of code that uses that part of the scheme either directly or indirectly must be updated. This kind of mismatch occurs because the component that manages data (the database) and the component that renders data (the user interface) is highly "coupled" with the database schema: the user interface needs to know _a lot_ about the data, its meaning, and its structure in order to render it meaningfully. +Even with carefully selected architectures, systems can still be difficult to put together, leading to *architectural mismatch*. When mismatch occurs, connecting two styles can require dramatic amounts of code to connect, imposing significant risk of defects and cost of maintenance. One common example of mismatches occurs with the ubiquitous use of database schemas with client/server web-applications. A single change in a database schema can often result in dramatic changes in an application, as every line of code that uses that part of the scheme either directly or indirectly must be updated. This kind of mismatch occurs because the component that manages data (the database) and the component that renders data (the user interface) are highly "coupled" with the database schema: the user interface needs to know _a lot_ about the data, its meaning, and its structure in order to render it meaningfully. The most common approach to dealing with both architectural mismatch and the changing of requirements over time is *refactoring*, which means changing the _architecture_ of an implementation without changing its behavior. Refactoring is something most developers do as part of changing a system. Refactoring code to eliminate mismatch and technical debt can simplify change in the future, saving time and prevent future defects. However, because refactoring remains challenging, the difficulty of changing an architecture is often used as a rationale for rejecting demands for change from users. For example, Google does not allow one to change their Gmail address, which greatly harms people who have changed their name (such as this author when she came out as a trans woman), forcing them to either live with an address that includes their old name, or abandon their Google account, with no ability to transfer documents or settings. The rationale for this has nothing to do with policy and everything to do with the fact that the original architecture of Gmail treats the email address as a stable, unique identifier for an account. Changing this basic assumption throughout Gmail's implementation would be an immense refactoring task.