Architecture as Code

Chapter 4. Constraints 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 4th 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].

Architectural constraints provide development teams with guidelines as to what is and isn’t allowed within the architecture. Constraints usually come from architectural decisions, such as “all communication between services will use request/reply messaging” or “the user interface cannot access the database directly.” Constraints are typically documented through Architecture Decision Records (ADRs), which record the context, justifications, and consequences of a decision.¹ While ADRs are a great way to document architecture decisions, they can’t enforce them. Architectural decisions have always been a challenge for architects to enforce and govern—until now.

How Constraints Are Formed

Architects make architectural decisions based on specific business requirements, which form constraints in the architecture that generally support important architectural characteristics. If development teams don’t implement those architectural constraints properly, the architecture ...