Skip to content
academia.sh
tr
Log in

Course Advanced

Architectural Styles

By the end of this course

Start course

01

Structural Styles

Arranging the units inside a program and the direction of dependency between them: what a layer rule is and what a leak looks like, ring arrangements where dependency turns inward, merging layer and ring into a single rule, the boundary of deployable software components, separating core from extension, and working through a shared blackboard for ill-structured problems.

  1. 01 Layered Architecture Writing the layered style as a declared set of permitted edges: splitting the shipment fee library into four layers, measuring the layers a request touches and the boundaries it crosses, counting the layers that pass a request through unchanged, and separating a declared open layer from an undeclared leak by violation count.
  2. 02 Hexagonal and Onion Architecture Comparing, as rules, two arrangements where dependency turns inward: counting the sixteen possible ring edges in a pricing context placed into four rings, separately deriving the edge sets forbidden by the hexagonal and onion rules, each rule seeing only one of two defects in the same codebase, and both counts dropping to zero after the repair.
  3. 03 Clean Architecture Merging two ring rules into a single predicate: writing the rule that forbids seven of sixteen ring edges, counting the edges — at the boundaries passing through the composition root — where the direction of control flow diverges from the dependency arrow, and comparing two data shapes crossing the boundary by accessible name and character count.
  4. 04 Component-Based Architecture Moving the unit from the ring to the releasable component: counting the number of names each component exposes and contains, comparing the co-release ratio across two partitions of the same files, measuring how a consumer that bypasses the surface raises the exposed name count, and counting the files a new capability edits, adds, and forces to re-release.
  5. 05 Microkernel and Plugin Architecture Separating an unchanging small core from plugins of unknown number: the core file's known plugin-name count falling from four to zero, measuring the number of lines edited in the core when a fifth plugin is added, the core running with a one-file closure with no plugins attached, and counting how many requests a contract-breaking plugin stops in each arrangement.
  6. 06 Blackboard Architecture Resolvers that do not know each other meeting through a shared field of information: the number of names units know about each other coming out to zero in determining a fee zone from an address, the extra reads and polls spent to reach the same result, the number of files a new resolver edits, and whether the result is deterministic across twenty-four poll orders.

02

Interaction Styles

Choosing the arrangement in which units talk to each other: separating roles into client and server, decentralized peer interaction, distributing the responsibility between the model and the view across controller, presenter, and view model variants, a pipe-and-filter chain for stream-based processing, event-based loose coupling, and queues and streams as the backbone of asynchronous integration.

  1. 01 Client–Server Measuring in code the separation of roles into initiator and waiter: the delivery side's count of names it must know about the pricing side dropping from four to one, which client breaks when the pricing side renames its own internal names, and the polling count as the cost of the waiting side not knowing the initiating side.
  2. 02 Peer-to-Peer Measuring the decentralized arrangement where the initiator and waiter roles merge into a single unit: the neighbor count six transfer hubs must know across three neighborhood arrangements, the round and message count required for a tariff update to reach everyone, the learner count when a unit is withdrawn, and the count of neighbor lists edited when a new unit is added.
  3. 03 Model–View Families Producing the same offer screen with controller, presenter, and view model variants, and turning the responsibility distribution into numbers: how many field names the displaying file recognizes, how many files the import closure spans, how many calls and how many bytes cross the boundary, and which files the order and format decisions sit in.
  4. 04 Pipes and Filters Processing the same daily shipment list in a single body and in a filter chain: measuring the number of fields each step reads, the number of fields crossing filter boundaries, the file edited and the number of fields that file reads when a new step is added, and the number of records simultaneously live when records are streamed one at a time.
  5. 05 Publish–Subscribe Comparing connecting the three jobs that run when a fee is finalized by direct call and through an event bus: measuring the number of modules and names the publisher knows, the import closure, the number of lines edited in the publisher when a fourth consumer is added, and the number of files that must be read to find handlers.
  6. 06 Message Queues and Streams Measuring the effect of putting a store between the publisher and the consumer: the consumer work unit run the moment a message is dropped, the number of pending messages when the consumer falls behind the producer, whether order is preserved with one and two consumers, the delivery record opened when a message is delivered a second time, and the number of history records a unit added afterward can read from a queue versus a stream.

03

Deployment Styles

The difference that comes from how many separate pieces the same software is published as: the simplicity and scaling limit of a single unit, enterprise-wide service sharing, the distributed complexity paid for independent release, systems built on event streams, the composition of functions and managed services, and choosing among all these arrangements by comparing them through quality attributes.

  1. 01 Monolithic Architecture Publishing two contexts of the same library as a single deployment unit: counting the boundaries an offer request crosses, its serialization points, and the bytes crossing the boundary; measuring how many files a one-file change republishes; and showing that a defect terminating the process brings down both contexts at once.
  2. 02 Service-Oriented Architecture Two contexts speaking through a single enterprise-wide record format and a single call path: measuring the canonical record's field count, the fields each service carries but does not read, the transformation points, and the bytes crossing the boundary; comparing these against a narrow contract; and counting the files edited when a field in the shared format changes.
  3. 03 Microservice Architecture What is gained and what is paid when the shared contract is removed: running two contexts as separate local processes, bringing the files republished per deployment unit down to 1, counting the boilerplate lines paid for independence, and measuring the number of endpoints that keep responding, and the partial response, when a process is stopped.
  4. 04 Event-Driven Architecture Reversing the direction of the call: counting the consumers the publisher knows and calls by name, measuring the line edited in the publisher file when a new consumer is added, computing how the bytes crossing the boundary and the transform points grow with the consumer count, comparing the number of requests answered when a consumer drops, and measuring the deviation between two consumer designs when the same event arrives twice.
  5. 05 Serverless Architecture The runtime responsibility leaving the application: counting the run lines left in the function files, measuring the number of files edited when composition moves into the manifest, measuring the result deviation module state produces on a cold run and the cost of moving state outside, and counting cold start by setup count while leaving its duration to a model.
  6. 06 Style Selection and Trade-off Analysis Turning a style decision into a measurable defense: measuring the same three rules on a common footing across two boundary arrangements, computing pass/fail against the threshold of three quality scenarios, showing that no arrangement passes all three thresholds at once, and finding the threshold that flips the decision.

Start typing to search.

↑↓ ↵ Esc navigate · open · close