Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
What Is Software Architecture? How It Differs from Design and What an Architect Does
Software architecture is the set of decisions that shape a system's important properties and are expensive to undo; between it and design there is no hard line but a spectrum from strategic to tactical. The SEI, ISO/IEC/IEEE 42010 and Fowler/Johnson definitions, FoSA's three laws, the architect's role and the Bookstore example used across the category.
Quality Attributes: Defining Architecture Characteristics with ISO/IEC 25010:2023
Architecture characteristics describe not what a system does but how well it does it, and they only produce decisions once tied to a domain goal and a number. The nine characteristics of ISO/IEC 25010:2023 and what changed since 2011, FoSA's classification, their .NET 10 counterparts and the top three chosen for Bookstore.
Quality Attribute Scenarios: Turning "Make It Fast" into a Measurable Requirement
A sentence like "make it fast" becomes a measurable, testable requirement through SEI's six-part quality attribute scenario (source, stimulus, environment, artifact, response, response measure). In the example, search looks fine with a 121 ms average but misses the target at p95 with 659 ms; prioritizing with a utility tree and connecting scenarios to tests and monitoring.
Trade-off Thinking: No Right Answer, Only the Least Worst Option
In architecture every option gains one characteristic at the expense of another; the job is to make the cost visible and accept it deliberately. In Bookstore, sending the order email synchronously ties checkout to SMTP and creates duplicate orders, while queuing it with Channel<T> brings checkout down to 1 ms but loses 3 emails when the process stops; one-way and two-way doors, the last responsible moment and writing down the why.
Layered Architecture: The Real Responsibilities of Presentation, Business, and Data Layers
The real promise of Layered Architecture is the isolation that closed layers provide, but because ProjectReference is transitive by default in .NET, Web silently sees Data through Business; DisableTransitiveProjectReferences moves that rule into the compiler. N-layer vs N-tier, closed and open layers, sinkholes, DB-centric design and the problem with the dependency direction.
Understanding the Monolith: Single-Process, Modular, and Distributed Monoliths
A monolith is not bad code but a single deployment unit; the real problem is the Big Ball of Mud, which forms in one process just as well as in twenty services. The difference between single-process, modular and distributed monoliths, module boundaries guarded by the compiler with internal, how a five-service synchronous chain misses a 99.9% target, and the Monolith First debate, all through Bookstore.
A Map of Architecture Styles: From Layered to Microservices, Which Style for What?
An architecture style is a set of constraints; with the axes of deployment-unit count and technical versus domain partitioning, layered, modular monolith, pipeline, microkernel, service-based, event-driven, space-based, SOA, microservices and Web-Queue-Worker fit on one map. Pipeline and AssemblyLoadContext-based microkernel examples, our own style table for Bookstore, and why Clean and Vertical Slice are code organization rather than styles.
Conway's Law: How Team Structure Shapes Architecture
Systems copy the communication structure of the organization that designs them: the same 14 commits need more than one team 86% of the time with layer teams and 21% with flow teams. Conway (1968), the Inverse Conway Maneuver, Team Topologies' team types and interaction modes, cognitive load, and two different right architectures for Bookstore with a team of 3 and with four stream-aligned teams.
Keeping Architecture Healthy Over Time: Architecture Erosion and Fitness Functions
Architectural decisions are protected not by code review but by fitness functions that run on every PR: a closed-layer rule with ArchUnitNET, a coupling threshold with a ratchet and a performance test that counts queries catch a PR that passes the build but breaks the architecture. Erosion and drift, kinds of fitness functions, a GitHub Actions step and a roadmap for the category.