Architecture as Code

Chapter 3. Structural Alignment

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the 3rd chapter of the final book. Please note that the GitHub repo will be made active later on.

If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at [e-mail].

In Chapter 2, we showed how the implementation of a system can get misaligned with its architecture if the development team doesn’t follow the architect’s guidelines regarding domains, subdomains, components, and component dependencies. In this chapter, we describe techniques for governing and ensuring these alignments.

Defining Domains and Services

Domains in monolithic architectures (those with a single deployment unit) are typically defined as the highest-level grouping of components. They represent a major part of the system from a functionality standpoint. For example, the Sysops Squad logical architecture, depicted in Figure 2-2 in Chapter 2, consists of two domains: Ticketing and Survey. Many other domains exist in this system, such as Reporting and Analytics, Administration, and Expert Knowledge Base, but we’ve chosen to limit our example to the primary ticketing flow for simplicity’s sake.

In distributed systems (those with separate deployment units), ...