Software Architecture Patterns

9.1 Patterns: Problem, Context, and Solution

Everything you studied so far in this course feeds directly into this topic, so keep that material at hand. This lecture is where the course comes together: quality attributes gave you the goals, tactics gave you the local moves, and patterns give you the big picture.

9.1.1 What a Pattern Is

Patterns are the big picture. Tactics are the smaller solutions used to fine-tune a pattern once it is in place. A pattern never stands alone; every pattern has to be viewed in the context in which it will be placed. If you know the context, and you know the problem you are trying to address, you can pick a pattern that fits.

The full definition is worth memorizing:

Why do we generalize? Because we cannot write a separate book for every case study. Similar situations appear again and again across industries, and we call those situations the context. The problems themselves repeat too. Typical generalized problems include:

• The same image must be shown in a number of different views.
• Fetching data from a remote server takes too long.
• Nobody knows which server to look at for the answer.
• There are too many choices of functionality, and it is not clear which one to use.
• The interfaces of components available in the market are simply not compatible with each other.

The context could be an online environment, a real-time environment, a shopping cart environment, or anything else. Where does the solution come from? You study the history of systems, you study how great designers solved problems, and you read the written studies. From all that, you identify components that interact in a particular manner. The solution then names those components and describes three things at once:

1. It states the responsibilities and relationships of the modules — the module structure.
2. It states the ways the components collaborate through connectors — the component-and-connector structure.
3. It states which physical components or which people are responsible for what — the allocation structure.

Finally, the solution gets a name, and that name is the pattern.

Reference books record each pattern against a fixed template, and the template itself teaches you how to read a pattern. A catalog entry typically lists: the pattern name (and any aliases), the context (the situation that gives rise to the problem), the problem, a summary of the solution, the strengths and weaknesses of that solution, the applicability (situations where you can use it), related patterns worth considering, and a reference for deeper reading. When you compare two candidate patterns for your design, the strengths and weaknesses entries are exactly what you weigh against each other.

Patterns come from experience. They come out of people who handled these situations, wrote research papers, and documented why they were convinced that certain ways of tackling a situation help realize certain quality attributes. In reality there are thousands of patterns on the internet, with no end to them. We study the basic ones. Prominent authorities have taken a few patterns and argued that if you understand those, you can derive or understand the others more easily. Textbooks have been written, structures have been created, and patterns of a particular type are grouped together.

9.1.2 Patterns as Shared Vocabulary

The real beauty of patterns is that they make it easy for professionals to interact. Think about how language itself works. Language is powered by literature: when you say "like a rose" or "like a deer", the imagery does not come from grammar, it comes from literature. When you say "you hit the nail on the head", nobody believes someone took an actual nail. It is a way of expressing shared understanding. Patterns work the same way for software people.

When you tell an IT person "model view controller", they immediately say "thanks, I've got it". Everyone else in the room, people from literature or history or geography, look at each other and wonder what was communicated. In fact a whole textbook has just been passed from one person to another in three words. Nothing more needs to be said.

Here is a small workplace scene that shows the same power.

People have implemented model view controller many times, and full reference texts exist — Microsoft, for example, publishes a complete treatment of MVC and of frameworks built on it. Documentation has been done, support structures have been built, and complex frameworks have been developed. Because the community works from patterns, your implementation job becomes much easier. Individual components inside a pattern may be implemented differently, and a single component may even be an entire subsystem, but the broad shape is agreed.

This vocabulary effect also explains why pattern names survive decades. New frameworks arrive every year, but the names layered, broker, and blackboard still carry the same meaning, so designs documented twenty years ago remain readable today. In industry, architecture reviews run on this shorthand: a reviewer who writes "consider a broker here" has communicated a whole solution family, its benefits, and its known risks in two words.

9.1.3 The Four Pattern Categories

Your textbook groups patterns into four broad categories. The nomenclature below follows the book.

From mud to structure. These are basic, rudimentary patterns usable almost anywhere for basic tasks — the name suggests imposing order on unstructured work. Three patterns sit here:

• Layered: divide the job into layers, each layer covering the layer below it, so you get specialization, can assign teams and functionality per layer, and get a thorough realization in each layer.
• Pipes and filters: like layering but flowing sideways; data flows through a chain of processing steps, each doing one process.
• Blackboard: disjointed knowledge groups put together for a particular purpose, like a teacher writing wherever he likes on a board.

This lecture walks through all three in detail: layered in 9.2, pipes and filters in 9.3, blackboard in 9.4.

Distributed systems. Here the activity is spread out, often geographically. The classic pattern is the broker. Picture two large groups of elements — typically a server group and a client group — that interact only through a broker in the middle. The broker allocates servers to clients or helps them reach each other. Reference books describe the mechanism precisely: services register with the broker, clients send requests to the broker, and the broker acts as the intermediary. This gives location transparency — services may relocate without clients ever knowing or caring — at the cost of extra message overhead, and the broker can become a bottleneck under heavy load.

Real-world: think of a property broker between landlords and tenants. If every tenant went directly to every landlord it would be a mess — language problems, communication problems, understanding problems. Tenants go to brokers, brokers go to landlords, and an appropriate match gets made. Stock market brokers work the same way: companies place stock in the market, and a broker gives you extra services and guidance beyond direct access.

Microkernel and adapter are also discussed under this family even though they appear elsewhere, and pipes and filters can distribute an architecture too, since its components may sit in different locations.

Interactive systems. These handle user-facing displays, reporting systems, and BI systems. They use either model view controller (MVC) or presentation abstraction control (PAC). MVC has been enormously popular: Smalltalk was a famous early realization, especially in Europe, and one recollection places Smalltalk alongside the Delphi database. Today MVC is widespread on Mac as well as Windows, with frameworks generated to realize its functionality. PAC appears in large reporting systems and integration systems where information integration matters; it helps you build MVC-type structures at different levels of abstraction, and it is popular in large information retrieval systems.

Adaptable systems. These are designed so they can adapt. Reflection is the first: if you have programmed in Java, you know Java can almost talk about itself. Commands let you find the name of a class, the methods in it, and the attributes available. This self-searching ability, built into the language, gives enormous scope for growth and makes the language useful far beyond routine programming. Microkernel is the second: at the virtual machine level you meet the JVM, Android's runtime, and Linux's innermost layer. The microkernel is the inner layer connecting the machine to the software. Kernel comes from the coconut — the inner shell. Huge systems are built on top of it, yet it keeps its essence, which is exactly why the system stays adaptable to changing requirements.

A quick way to hold the map in your head: mud-to-structure patterns build order where none exists; distributed patterns place that order across machines; interactive patterns point it at the user; adaptable patterns keep it flexible after delivery. Every specific pattern you meet later sits somewhere on this map.

9.1.4 Reading and Drawing Views

A question came up earlier about what the various types of views actually look like. Searching image galleries for "software architecture module views" returns plenty: decomposition views, uses views, layered views, class views — most of these are module views, where you split the application into boxes and connect them to show how the work is divided. Searching for component-and-connector views shows components joined by connectors, where each connector indicates some kind of communication between components. Allocation views show which physical component or which humans are responsible for each part. There is no shortage of examples, and browsing such pages before the exam is not a bad idea.

In this course we are not concerned with drawing skill or syntactically perfect UML diagrams. As long as you convey the meaning, even non-standard terminology is accepted — provided you give a small key explaining the terms you invented.

Real-world: the most popular industry tool for this kind of modeling has long been Rational Rose, from IBM. For coursework, StarUML is a fine open-source choice, and it is a modeling tool rather than a drawing tool — once you enter the model elements, converting from one view to another becomes nearly automatic. That distinction matters: a drawing tool stores pixels, while a modeling tool stores the model elements themselves, so the tool can regenerate a class view from an object view without you redrawing anything.

9.1.5 Questions and Answers

Several questions came up around answering technique and exam expectations. They are collected here because the answers apply to every topic in the rest of the course.

The next question is about the overall shape of the paper itself.

A related worry is how much detail to give when a question offers a choice.

The next trap catches even well-prepared students, because both instruments are called "scenarios".

On the practical side, students often ask whether tool skills are part of the syllabus.

With the vocabulary and the map of categories in place, the next three sections walk through the mud-to-structure patterns one at a time, starting with the most used of them all: layers.

9.2 The Layered Pattern

9.2.1 Context: Independent Development and Evolution

All complex systems feel the need to develop and evolve portions of the system independently. You have a very large system, and you want independent teams — maybe independent companies, even entire corporations — working on one portion. For that to work, the communication protocol between layers must be well established. When several corporations cooperate on one system, they form committees that agree on the interfaces, sometimes as international protocols.

Three goals drive the design:

1. Portability: a particular layer should be completely substitutable and usable in a different context.
2. Isolated change: you should be able to modify each layer without impacting the other layers.
3. Reuse: each layer should be reusable in different contexts.

Reference books list this pattern under names such as layers of abstraction or hierarchical layers, and record its typical applications as operating systems, communication protocols, and software product lines — exactly the settings where independent evolution matters most.

9.2.2 Solution: Cohesive Layers with a One-Way Usage Rule

Drawn as a picture, the pattern is a stack of boxes where every arrow points down and no arrow ever points up:

    +---------------------------+
    |     Layer A  (highest)    |  uses services of B
    +---------------------------+
    |     Layer B               |  uses services of C
    +---------------------------+
    |     Layer C               |  uses services of D
    +---------------------------+
    |     Layer D  (lowest)     |  talks to the machine
    +---------------------------+

Add a small key naming each box when you draw this in an exam; the key removes any confusion about what A, B, C, and D mean.

Why insist on one-way usage? Consider how companies departmentalize. In a company you do not make your own coffee: you use an app, contact the facilities people, and collect the coffee they prepared. You do not open your PC and swap the hard disk yourself, even if you know how: you get approval from your team lead and hand it to the maintenance group. Many people dislike this and ask why they cannot do everything themselves, or why help cannot flow both ways. But the rule stands, and it exists to prevent deadlock.

Without the rule you get the situation of passengers at a train door, each insisting the other goes first, so nobody goes anywhere. Circular references are the technical version of that deadlock. Anyone who has linked software modules knows what a circular reference can do: module X waits for Y to finish while Y waits for X, and neither moves. The only place cycles help is the cyclic redundancy check; anywhere else — cyclic computation in Excel, for example — you run into a problem. So the protocol is strict: if a lower layer requires a service from the layer above, that is not possible.

Departments also explain when layering is worth it. A small company sits in one room and works together — the early days of Microsoft were exactly that, everyone in one room. Today Microsoft has layers, hierarchies, and many forms of organization structure. And notice something deeper: the compartments are the module structure, the interaction between compartments is the component-and-connector view, and the assignment of tasks to compartments is the allocation view. It is the same system viewed in different ways — you do not design one system per view.

9.2.3 Worked Example: The OSI Seven-Layer Model

9.2.4 TCP/IP Walkthrough

The two stacks line up layer-for-layer, which is why networking courses teach them together:

When to pick which picture: OSI gives you the finer vocabulary for discussion and exams; TCP/IP is what the internet actually runs, so real equipment follows the coarser four-to-five level split.

9.2.5 How to Build Layers: Step-by-Step

Layering is a procedure as much as a picture. The inputs are the required functionalities and any team or vendor boundaries; the outputs are designed layers with specified interfaces and an error handling strategy. The procedure given for creating layers runs as follows:

1. Understand what functionalities are required.
2. Determine the number of layers.
3. Assign tasks to each layer.
4. Specify what services will be required.
5. Detail out the layers.
6. Specify the interfaces that will exist between the layers — what each layer takes from the layer below.
7. Design the internal structure of each layer.
8. Specify the communication between adjacent layers and how they work with the protocol.
9. Separate out each layer and make them available for working separately.
10. Design the error handling strategy for communication between the layers.

Two steps deserve extra attention. Step 6 is the contract step: whatever you write there becomes the agreement that lets teams work separately, so vague interfaces poison every later step. Step 10 exists because a failure in a lower layer must be reported upward in a form the upper layer can act on — the upper layer should never inherit raw low-level errors it cannot interpret.

Cost note: more layers mean cleaner separation but longer call chains. Every request pays a small tax at each boundary, so the number of layers is a real design decision, not a default.

9.2.6 Variants

Variants exist because architects get inspired by the general structure of a pattern and then adjust it, sometimes relaxing rules. You may relax the rule forbidding calls to the upper layer if, after due consideration, that simplifies the design — reference books even name a flexible layers variation for this. Another variant is layering through inheritance: in object-oriented systems, implement a layer as a base class and add subclasses with more and more specialization. Since that handles different functionalities at different levels of abstraction, it counts as a layer design too.

9.2.7 Virtual Machines, APIs, and N-Tier Usage

The most popular usages of the layered pattern are virtual machines. The JVM — the Java virtual machine — separates your application software from the implementation of the hardware, and it is a beautiful realization. The same Java application, compiled to bytecode, runs on any machine that implements the JVM, as long as the machine supports the functionality.

Picture every car manufacturer implementing a JVM that exposes the car's functions. A program written against that common protocol could be loaded on a BMW and copied into a Mercedes. It would run unchanged on Volkswagen, Opel, Audi — any of them — because the lower layers differ but the JVM contract holds. The Dalvik virtual machine did the same for Android: a world full of programmers writes apps without knowing or caring whether the phone is a Samsung, Huawei, Xiaomi, or Redmi, as long as it runs the virtual machine.

The microkernel idea sits right next to this. Recall the coconut: kernel comes from the inner shell, and the microkernel is the innermost layer connecting the machine to the software. Huge systems are built on top of it, yet it keeps its essence — which is exactly why the system stays adaptable to changing requirements. The JVM plays precisely that kernel role for Java programs: one stable essence under many changing machines.

Layering also explains modern API practice. API engineering has become a big subject with active research and strong employment scope, because a good API lets you use an entire application as an abstraction. If you code a front end for Uber, you simply use the layer provided by Google. You never worry about the layers behind it — they might be blackboard structures, layered structures, anything. Patterns can be mixed and matched. Each layer only has to follow the standard protocol agreed in its community, and communities form international forums where companies establish standards for APIs. Resources behind your layer may be your own or third party; either way, interaction works because the protocol is agreed.

Tier counts vary: people started with two-layer architectures, moved to three, and some prefer four. Typically you find a presentation layer, an application logic layer (often called the business logic layer), a domain layer, and at the bottom the database, far removed. Specialists can work at each level, and large companies ship frameworks supporting programming in each of these layers. Windows NT is a commonly cited layered usage.

One vocabulary point trips people up: a layer is a logical grouping of functionality, while a tier is a physical placement on separate machines. The same names appear in both worlds — presentation, business, data — but only tiers imply separate servers. Two-tier means client plus database server; three-tier adds an application server between them; n-tier splits the web server from the application server as well, often for security. Several layers usually live together on one machine, and splitting into tiers is a deployment decision made for scale or security, not a new design.

Specialists work per level in practice: interface designers own the presentation layer, business analysts shape the business logic layer, and database specialists tune the bottom. That division of labor is the allocation view of the same layered design.

9.2.8 Benefits and Liabilities

Benefits: you can reuse the layers; you support standardization; dependencies are kept local, so you never have to expose them. Exchange a layer for another implementation of the same contract — a new database engine under an unchanged business layer — and nothing above notices.

Liabilities: cascading calls lower efficiency, because a request travels down through every intervening layer. Behavior may change while cascading — things happen that you may not be aware of. Some work looks unnecessary, yet in larger systems a certain amount of unnecessary-looking work is exactly what keeps complexity away. Finally, establishing correct granularity is hard: deciding what belongs in which layer poses real problems. Put too little in a layer and it becomes a hollow pass-through; put too much in and the isolation you wanted disappears.

Real-world: beyond networking, layered structure runs your daily software — the JVM and Android runtime isolate applications from hardware, Windows NT organizes its internals in layers, and every web app that separates interface, business logic, and database is speaking this pattern. Communication protocol stacks like OSI and TCP/IP remain the cleanest public examples, which is why standards committees still publish layer diagrams when two vendors must interoperate.

9.3 Pipes and Filters

9.3.1 Context and Solution

The connection between components is called a pipe, and each component is called a filter — named because it changes the data passing through it: certain things are removed, certain things are added. A coffee filter is the everyday version: grounds stay behind, brewed coffee flows on. Software filters do the same to data — drop what is not needed, transform what is, pass the rest downstream.

Think of an assembly line in a car wash. Stations stand in a row: foam, scrub, rinse, dry. The conveyor belt between them carries the car from station to station, and each station does exactly one job to whatever arrives. You can bolt on a waxing station at the end without touching the others, and the belt does not care which brand of scrubber sits in the middle — only that a car rolls in one side and rolls out the other. That is the whole pattern: stations are filters, the belt is the pipe. Where the analogy stops: a car wash has one fixed order, while filters can often be recombined freely as long as their data formats agree.

The context: you need a system that handles a wide variety of work, with input-output processing combined differently for different situations, all the time. The processing steps are complex scripts, difficult jobs, but you want to reuse them across systems. The modules do not require each other individually, yet together they deliver the purpose.

The solution: create each module with a specific input and a specific output, kept structurally compatible with each other. Similar structure on inputs and outputs across units lets a large number of them share common inputs and outputs. Once that holds, you can plug and play in whatever order and sequence you like, and you can even create parallelism inside the pattern.

Drawn as a picture, the pattern runs left to right instead of top to bottom:

        pipe          pipe           pipe           pipe
in --->[ scan ]---> [ parse ]--->[ analyze ]--->[ generate ]---> out

Each box reads its input stream, transforms it, and writes its output stream; the arrows are the pipes carrying data between them. Compare this with the layered stack of 9.2: layers pile authority downward, while filters line up sideways along the flow of data.

9.3.2 Worked Example: Building a Compiler Pipeline

 source ---> [ scanner ]--->[ parser ]--->[ semantic ]--->[ code      ]---> interpreter
   code        tokens        grammar       analyzer         generator         execution
                             checking       meaning          machine code

9.3.3 Worked Example: Unix Command Pipelines

ls | sort | grep -v "draft" | sed "s/report/summary/g" | tee result.txt

Do not worry if you have never used Unix. It is a very old operating system that is going strong, with Linux as its major open-source variant and many service providers running on it. Windows has a command line too, and from Windows 10 onwards PowerShell offers marked similarity: you chain script commands that control the operating system. Sun Solaris and Mac OS behave the same at the command level. If you understand the Unix command structure, you understand pipes and filters.

9.3.4 Implementation Steps

To implement pipes and filters in an application:

1. Identify the tasks and divide them into modules.
2. Decide the data format for movement of data between the filters.
3. Implement each connection — outputs to inputs.
4. Implement each filter's conversion of input to output.
5. Take care of error handling, so that if data produced does not fit the next level there is control on the output and control on the input.
6. Set up the pipeline and verify that all the combinations you require actually work.

Step 2 is where the design lives: the shared data format is the contract that makes plug-and-play possible, so decide it before writing any filter. Step 6 matters more than it sounds — recombination is the point of the pattern, so verify the combinations you plan to support, not just one happy path.

The tee arrangement is a small variant for parallel flow: instead of sending data to one input, a tee sends it to two places. The typical requirement is one flow continuing downstream while a copy displays on the console. CMS pipelines and LASP tools are other common usages.

9.3.5 Benefits and Liabilities

Benefits: no intermediate files are necessary — you never dump output to a file just to process it again. Exchange between modules is flexible: you can recombine modules, skip an element, add an element, even reorder them. You can set up a prototype very quickly: try a suggestion, see the result. And with tee you get parallel processing.

Liabilities: the setup is expensive if you need it only for the short term — it pays off for systems used over a long period. There is format overhead: at every stage the data must be ready in a stringent format, whereas one combined program would not care. And error handling between components must be engineered explicitly, because no filter knows anything about its neighbors' internal failures.

Real-world: beyond shells, this shape powers compiler toolchains whose stages come from different teams, extract-transform-load pipelines that move data between systems overnight, and media encoders that chain decoding, filtering, and encoding stages. Anywhere engineers say "pipeline", they are speaking this pattern.

9.4 The Blackboard Pattern

9.4.1 Context: No Fixed Plan, Many Specialists

The name comes from a classroom picture. A teacher writes on the blackboard randomly, wherever he feels like, and disjointed knowledge groups get put together for a particular purpose. Nothing about the board dictates the order of writing; the argument takes shape from whatever gets added, whenever it gets added.

Extend that picture to a hospital case conference. The patient chart lies open in the middle of the table — that is the blackboard. A cardiologist reads it and adds a note; a radiologist adds another; the chair watches the chart and decides whose finding should be examined next. No specialist talks to another directly; they all communicate by writing on the shared chart, and a diagnosis assembles piece by piece. Where the analogy stops: in a meeting people also chat in the corridor; in the pattern, knowledge sources talk only through the board.

Very advanced systems fit this shape — systems that must use lots of functionalities and call them from here and there. With a blackboard you can invoke all those specialized modules in whatever combination the moment demands.

        [ KS: sound analysis ]
                  |
                  v
[ KS: grammar ] ---> ( BLACKBOARD ) <--- [ KS: words ]
                          ^
                          |
                  [ KS: service lookup ]
             (control picks who writes next)

The picture is the classroom again: one board in the middle, specialists around it, and no fixed speaking order. Compare with 9.3: pipes and filters fixes the sequence of transformations in advance; blackboard leaves the sequence open and lets the state of the problem decide it.

This idea was born in speech understanding research: the classic Hearsay-II system of the 1970s connected waveform, syllable, word, and sentence specialists through one shared board because nobody could write a single fixed algorithm that went straight from sound to meaning. Every modern voice system inherits that shape.

9.4.2 Worked Example: Voice Assistants

9.4.3 Questions and Answers

Within its proper domain, the pattern still has traps that cost real debugging time.

Real-world: Alexa and Siri run this shape daily, coordinating acoustic, language, and service-integration specialists to fetch songs across Spotify, Amazon Music, Saregama, and Gaana. Beyond assistants, the same pattern organizes expert systems that combine rule sets from different domains, and fusion software that merges readings from many sensors into one picture of the world.

Exam Guidance Summary

• Scope: the midterm covers modules 1 to 5, contact sessions 1 to 8. Content from session 9 onwards (patterns) is not in the midterm but is included in the comprehensive examination, which spans the entire course.
• Format: closed book. Diagrams may be scanned and uploaded, but they must be handwritten — no printed material may be scanned.
• Upload strategy: do not wait until the end of the exam to scan and upload; finish a question, upload it. Treat the last days of any submission window as buffer, not as working time. Never send scans to course staff hoping something happens — examination matters go through the examination department and its support team.
• Time budget: distribute time by marks. With 120 minutes and 30 marks, give $\frac{120\text{ minutes}}{30\text{ marks}}=4$ minutes per mark. If one question eats too much time, drop it, summarize it, move on — the 80-20 rule applies to answers. Dumping all your knowledge on one question buys little: if everyone scores 8 out of 10, your 9 helps marginally, but a 0 elsewhere sinks you.
• Read every question very carefully. Even if you do not understand a question, write down your interpretation and answer that.
• Case studies: answers must refer to the given case study; reproducing memorized notes or web text is never good enough.
• Tactics: select appropriate tactics and explain them rather than listing everything under a quality attribute.
• Quality scenarios: produce the six-part form — stimulus, source of stimulus, environment, artifact, response, measurement of response — never use case text.
• Management alternatives: know the six or seven approaches at the end of each quality attribute topic, and apply them within the case study context.
• Coverage: this is a split-mode course. The recorded video lessons from the core faculty act as the basic text, and contact sessions complement (explain and contextualize) and supplement (add to) them. Do not enter the exam hall without at least viewing all the provided decks and the recorded lessons. Browse example images of module, component-and-connector, and allocation views beforehand.
• Mixed answer formats (partly scanned, partly typed) were accepted up to last year; check current announcements, and attend any trial session the examination system offers by email.

Key Industry Applications

• ERP and CRM platforms: Salesforce (CRM), SAP, and Oracle Apps are internationally established packages; building an ERP usually means either a very large organization redeveloping or improving one, or a smaller firm producing customized systems for clients. The architect's influences — organization size, client priorities, existing packages — decide the shape of the result.
• Modeling tools: Rational Rose (IBM) dominates industry; StarUML is the favored open-source modeling tool, converting between views automatically once the model is entered. Modeling tools store model elements rather than drawings, which is what makes view-to-view conversion possible.
• Operating system pipelines: Unix, Linux, Sun Solaris, and Mac OS command chains, plus PowerShell on Windows 10 onwards, realize pipes and filters daily; CMS pipeline and LASP tools are further uses. Every shell one-liner chained with vertical bars is the pattern in production use.
• Virtual machines: the JVM gives Java platform independence — recall the car analogy where one program runs on BMW, Mercedes, Volkswagen, Opel, and Audi alike. The Dalvik virtual machine lets one Android app run on Samsung, Huawei, Xiaomi, or Redmi hardware. Both realize layered structure: a stable contract above, interchangeable hardware below.
• APIs: API engineering is a research field and employment area; an Uber front end simply consumes the layer Google exposes, blind to the architecture behind it, while international forums standardize the protocols. Patterns mix freely behind an API boundary.
• Networking: the OSI seven-layer model and TCP/IP over ethernet structure all internet communication, with market equipment commonly combining network and data link, or presentation and session, layers. Layered thinking here is so settled that standards committees publish layer diagrams by default.
• Voice assistants: Alexa and Siri apply the blackboard pattern. Waveform analysis, syllables, words, dictionary and grammar checks, sentence assembly, and command execution combine to fetch songs across Spotify, Amazon Music, Saregama, and Gaana.
• History: Smalltalk was a popular early MVC realization, remembered especially in Europe alongside the Delphi database; early Microsoft ran with everyone in one room before growing into layered organizational structure. Pattern names keep such histories readable decades later.