Architecture as enforceable boundaries: patterns and the price of each constraint

The fourth unit moves from what the product must do to the boundaries it must hold, and to what each costs. Architecture is usually taught as drawing: boxes placed, arrows drawn, the diagram presented as the design. A diagram has never stopped anybody from reaching across a boundary. A boundary counts as architectural when the team can say who or what enforces it. A pattern earns its name only when somebody states the constraint it imposes together with the price it charges.

The decisions worth writing down must hold while the code changes, and they must be detectable when broken. Examples are a direction of dependency, a deployment unit, a schema owner and a quality budget. The reputation of a named pattern is not evidence about quality.

The claim: a boundary somebody can enforce

Parnas (1972) is the origin of the argument that a boundary is a decision about change rather than a step in a computation. The first followed processing steps, and the second hid a decision likely to change. He showed that the second is better for flexibility and comprehensibility, and he recorded a price: it would be less efficient in most cases under a conventional implementation. Bass, Clements and Kazman (2012) add the test used here. A structure is architectural only when it supports reasoning about a property that matters to a stakeholder.

The system he decomposed twice is the KWIC index. It prints every circular shift of every input line in alphabetical order. The conventional version gives one module to each processing step: reading, shifting, alphabetising and printing. A change to the way the index holds its data therefore runs through all of them. The information-hiding version gives one module to each decision that the rest of the system does not need to know. The line store therefore hides how characters are packed, and the rest of the system reaches the shifter through named functions (Parnas, 1972).

The first boundary is a direction of dependency

Krasner and Pope (1988) set out model-view-controller in Smalltalk-80. The model does the work of the domain. Views display it, and controllers turn input into messages to the model. Views and controllers know their model. A model must not know about its views. The views register as dependents, and the model notifies them on change. The pattern itself is one enforceable sentence about who may know whom.

Fielding (2000) states constraints with their bills attached. He derives REST by adding constraints to a style with none. Statelessness means that every request carries what a receiver needs to understand it. It buys visibility, reliability and scalability, at the cost of repeated data and weaker server control across client versions. Repeated data is paid for on a metered connection, and the client that cannot be updated is often an older device.

A pattern is a name plus a price, and the price is seldom measured

Gamma, Helm, Johnson and Vlissides (1994) catalogued twenty-three patterns. Each comes with the circumstances in which it applies and the trade-offs of using it in a larger design: constraint first, price second. The evidence is design experience rather than measurement. The book claims that the extra effort invariably pays dividends in flexibility. That claim is an assertion about the price, not an observation of it. Fowler (2002) catalogued roughly forty enterprise patterns, and he notes later that frameworks now implement many of them. The price therefore becomes the framework's to state.

The price is measurable, uneven, and it arrives as a smell

Ampatzoglou, Chatzigeorgiou, Charalampidou and Avgeriou (2015) tested the shielding claim directly. They performed change impact analysis on about 65,000 classes from 537 open-source Java projects. Classes that play exactly one pattern role are more stable than those that play none or several, but the significance varies across domains. Coupled occurrences are the least stable. Pattern classes do not differ significantly from non-pattern classes overall.

Wedyan and Abufakher (2020) reviewed the wider evidence. They reduced 804 candidate papers to 50 primary studies covering 2000 to 2018, with effects conflicting and hard to compare. Documentation of the pattern, class size and how far a pattern is scattered have a clear impact on quality. Case studies used different metrics on different modules, so the price includes stating a pattern precisely enough to be measured.

Garcia, Popescu, Edwards and Medvidovic (2009) gave the failure mode a name. Architectural bad smells are recurring design fragments with non-obvious effects on lifecycle properties such as maintainability. The authors describe four of them, found while they reverse-engineered eighteen grid technologies and refactored one large industrial system. An architecture rarely breaks as a defect. It accumulates decisions whose cost was never stated, and the cost arrives as work on every later change.

The largest boundary claims the largest price

Fowler and Lewis (2014) describe the most ambitious version. An application becomes a suite of small services, each in its own process, around business capabilities and independently deployable by automated machinery. Each service is a firm module boundary, though the authors insist that this describes common characteristics rather than a definition. The problem is enforceable. In a monolith the change cycles tie together, and a change to a small part requires rebuilding and deploying the whole. Independently deployable is a claim a pipeline can test.

Taibi, Lenarduzzi and Pahl (2018) mapped reported microservice usage. They concluded that different patterns emerge for different migration, orchestration, storage and deployment settings. A name carried from one setting to another arrives without its price.

Soldani, Tamburri and Van Den Heuvel (2018) priced the style in a review of 51 industrial studies published between 2014 and 2017. The pains fall on service granularity and security at design, on distributed storage and testing at development, and on resource consumption at operation. Practitioners raise transaction complexity in 18 studies and query complexity in 9. The review records what practitioners wrote rather than what anybody measured.

Laigner, Zhou, Salles, Liu and Kalinowski (2021) combined a systematic review, an analysis of open-source applications and a survey cross-validated with more than 120 practitioners. They concluded that data management in microservices needs system-level support rather than practice alone. Decomposition moves the price of consistency into the data layer.

Contested question: does a named pattern earn its keep, and against which measure?

Different literatures hold three positions. The canon of practice treats a pattern as a solution compiled from real systems, so practitioners know its consequences and state them (Gamma and others, 1994). Fowler (2002) and Bass and others (2012) embed that view in architecture. A second position holds that context indexes the price. Ampatzoglou and others (2015) found that stability depends on role, coupling and domain, with no significant aggregate difference between pattern and non-pattern classes. Wedyan and Abufakher (2020) found the studies conflicting, partly because their metrics differ. Taibi and others (2018) found that which pattern applies depends on the deployment and storage setting. A third position locates the harms in architectural smells rather than component defects (Garcia and others, 2009), and the price of the service boundary in operations and data management, where the practice literature claims the gains (Soldani and others, 2018; Laigner and others, 2021).

The disagreement is narrow, since nobody denies that boundaries must be drawn. One study would settle it. In that study the pattern and its role are the independent variable, and the record includes implementation and documentation. The study reads the outcome from artefacts such as change propagation or rework, and it measures the price in the same units as the benefit. Ampatzoglou and others (2015) come closest, and Wedyan and Abufakher (2020) name what is missing, but no study here does all of it.

What to do while the dispute is open

The evidence on the two sides is unequal. The case for a pattern rests on design experience compiled from real systems (Gamma and others, 1994). The case against rests on a change-impact analysis of about 65,000 classes from 537 projects and a review of 50 primary studies, and both report context-dependent effects (Ampatzoglou and others, 2015; Wedyan and Abufakher, 2020). The strongest objection to this unit's thesis is that an unenforceable boundary may still be the right design, because the constraint can live in a convention rather than in a mechanism. While the dispute is open, a designer should state each boundary's price in the units it will be paid in, and prefer the boundary that somebody can point to as enforced.

Where the argument is heading

The direction is to make the price part of the artefact rather than of the folklore. Wedyan and Abufakher (2020) ask for unified metrics and for studying how pattern structure can be improved, turning a catalogue entry into a design hypothesis. Ampatzoglou and others (2015) make instability a per-role, per-domain measure and propose it for prioritising testing and refactoring. Laigner and others (2021) point to infrastructure, where part of the price should be paid once rather than by each team.

The sources this unit rests on

Two papers on the plan's list are absent. Laigner and Zhou (2024) is a two-page conference abstract whose page range in the plan conflicts with the registry record, too thin for a claim about benchmarked trade-offs. Shaw and Garlan (1996) is dropped as the least load-bearing source at this length.

• Parnas, D. L. (1972). On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM 15(12), 1053-1058. doi:10.1145/361598.361623 One system is decomposed twice, by processing steps and by hiding a decision likely to change; the second is better for flexibility and comprehensibility but less efficient under a conventional implementation. The boundary is stated together with its price.
• Krasner, G. E. and Pope, S. T. (1988). A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80. Journal of Object-Oriented Programming 1(3), 26-49. https://perso.lisn.upsaclay.fr/mbl/ENS/FONDIHM/2013/papers/Krasner-JOOP88.pdf The report describes model-view-controller in Smalltalk-80, where views and controllers are registered dependents that a model must not know about. It supplies the canonical boundary as a direction of dependency.
• Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. PhD dissertation, University of California, Irvine. Chapter 5: Representational State Transfer (REST). https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm REST is derived by adding constraints to a style with none, each given with the properties it induces and the price it charges; statelessness buys visibility, reliability and scalability at the cost of repeated data and weaker server control across client versions.
• Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA. https://www.informit.com/store/design-patterns-elements-of-reusable-object-oriented-9780201633610 The catalogue names twenty-three patterns, each with the circumstances in which it applies and the trade-offs of using it in a larger design. It was compiled from real systems, so the evidence is experience rather than measurement.
• Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley, Boston, MA. https://martinfowler.com/books/eaa.html The book catalogues roughly forty patterns across layering, domain logic, relational mapping, presentation, distributed design and concurrency spanning transactions, and its author notes later that frameworks now implement many of them.
• Bass, L., Clements, P. and Kazman, R. (2012). Software Architecture in Practice. 3rd edition. Addison-Wesley, Upper Saddle River, NJ. https://www.sei.cmu.edu/library/software-architecture-in-practice-third-edition/ Architecture is defined as the set of structures needed to reason about the system, and a structure is architectural only when it supports reasoning about a property that matters to a stakeholder. Architects should work from prioritised quality attribute requirements.
• Garcia, J., Popescu, D., Edwards, G. and Medvidovic, N. (2009). Identifying Architectural Bad Smells. In 2009 13th European Conference on Software Maintenance and Reengineering (CSMR 2009). IEEE, 255-258. doi:10.1109/CSMR.2009.59 The authors define architectural bad smells as recurring design fragments with non-obvious effects on lifecycle properties, distinct from antipatterns and code smells, and report four from reverse-engineering eighteen grid technologies.
• Ampatzoglou, A., Chatzigeorgiou, A., Charalampidou, S. and Avgeriou, P. (2015). The Effect of GoF Design Patterns on Stability: A Case Study. IEEE Transactions on Software Engineering 41(8), 781-802. doi:10.1109/TSE.2015.2414917 Change impact analysis over about 65,000 classes from 537 open-source Java projects found classes playing exactly one pattern role more stable than those playing none or several, with significance varying by domain, while coupled occurrences are least stable. It is the direct test of the shielding claim.
• Fowler, M. and Lewis, J. (2014). Microservices: A Definition of This New Architectural Term. https://martinfowler.com/articles/microservices.html The article describes an application as a suite of small services, each in its own process, around business capabilities and independently deployable by automated machinery, while insisting that this describes common characteristics rather than a definition. It supplies the definition the unit tests.
• Taibi, D., Lenarduzzi, V. and Pahl, C. (2018). Architectural Patterns for Microservices: A Systematic Mapping Study. In Proceedings of the 8th International Conference on Cloud Computing and Services Science (CLOSER 2018). SciTePress, 221-232. doi:10.5220/0006798302210232 The mapping study extracted patterns and principles from reported microservice case studies and catalogued them with advantages, disadvantages and lessons learned for each. It concludes that different patterns emerge for different migration, orchestration, storage and deployment settings.
• Soldani, J., Tamburri, D. A. and Van Den Heuvel, W.-J. (2018). The pains and gains of microservices: A systematic grey literature review. Journal of Systems and Software 146, 215-232. doi:10.1016/j.jss.2018.09.082 A review of 51 industrial studies published between 2014 and 2017 found the pains in service granularity and security at design, distributed storage and testing at development and resource consumption at operation, with transaction complexity raised in 18 studies and query complexity in 9. It supplies the price side of the service boundary.
• Wedyan, F. and Abufakher, S. (2020). Impact of design patterns on software quality: a systematic literature review. IET Software 14(1), 1-17. doi:10.1049/iet-sen.2018.5446 The review covers 2000 to 2018, reduces 804 candidate papers to 50 primary studies, and reports that documentation, class size and pattern scattering affect quality while case studies and experiments disagree in metrics and design. It is the aggregate verdict on whether patterns improve quality.
• Laigner, R., Zhou, Y., Salles, M. A. V., Liu, Y. and Kalinowski, M. (2021). Data management in microservices: State of the practice, challenges, and research directions. Proceedings of the VLDB Endowment 14(13), 3348-3361. doi:10.14778/3484224.3484232 A systematic review, an analysis of open-source applications and a survey of more than 120 practitioners found data management challenges that practice alone cannot solve and that need system-level support. It carries the counterweight on where the price of decomposition is paid.