software design and architecture case study examples

• Publications
• News and Events
• Education and Outreach

Software Engineering Institute

Case Studies in Software Architecture

December 13, 2017 • collection, topic or tag.

More and more organizations are realizing the importance of software architecture in their systems' success in areas such as avionics systems, network tactical systems, internet information systems, architecture reconstruction, automotive systems, distributed interactive simulation systems, scenario-based architectural analysis, system acquisition, and wargame simulation systems. 

The SEI can provide information and guidance about architecture-related questions and problems. Please contact us . Below are published case studies of real-world applications of architecture-centric engineering. They include case studies using

• architecture evaluation, analysis, and design
• the Architecture Tradeoff Analysis Method (ATAM)
• the Quality Attribute Workshops (QAW)
• architecture reconstruction

Collection Items

A principled way to use frameworks in architecture design, november 30, 2012 • article, by humberto cervantes (universidad autonoma metropolitana–iztapalapa) , perla velasco-elizondo (autonomous university of zacatecas) , rick kazman.

In the past decade, researchers have devised many methods to support and codify architecture design.

Developing Architecture-Centric Engineering Within TSP

April 1, 2013 • brochure, by software engineering institute.

This information sheet describes the Bursatec project.

Relating Business Goals to Architecturally Significant Requirements for Software Systems

April 30, 2010 • technical note, by paul c. clements , len bass.

The purpose of this report is to facilitate better elicitation of high-pedigree quality attribute requirements. Toward this end, we want to be able to elicit business goals reliably and understand …

System Architecture Virtual Integration: An Industrial Case Study

October 31, 2009 • technical report, by peter h. feiler , jörgen hansson (university of skovde) , dionisio de niz , lutz wrage.

This report introduces key concepts of the SAVI paradigm and discusses the series of development scenarios used in a POC demonstration to illustrate the feasibility of improving the quality of …

Evaluating Software Architectures: Methods and Case Studies

October 22, 2001 • book, by paul c. clements , rick kazman , mark h. klein.

This book is a comprehensive guide to software architecture evaluation, describing specific methods that can quickly and inexpensively mitigate enormous risk in software projects.

Scenario-Based Analysis of Software Architecture

November 1, 1996 • white paper, by gregory abowd , len bass , paul c. clements , rick kazman.

This paper presents an experiential case study illustrating the methodological use of scenarios to gain architecture-level understanding and predictive insight into large, real-world systems in various domains.

An Architectural Analysis Case Study: Internet Information Systems

April 1, 1995 • white paper.

This paper presents a method for analyzing systems for nonfunctional qualities from the perspective of their software architecture and applies this method to the field of Internet information systems (IISs).

Using the SEI Architecture Tradeoff Analysis Method to Evaluate WIN-T: A Case Study

August 31, 2005 • technical note, by paul c. clements , john k. bergey , dave mason.

This report describes the application of the SEI ATAM (Architecture Tradeoff Analysis Method) to the U.S. Army's Warfighter Information Network-Tactical (WIN-T) system.

Using the Architecture Tradeoff Analysis Method (ATAM) to Evaluate the Software Architecture for a Product Line of Avionics Systems: A Case Study

June 30, 2003 • technical note, by mario r. barbacci , paul c. clements , anthony j. lattanze , linda m. northrop , william wood.

This 2003 technical note describes an ATAM evaluation of the software architecture for an avionics system developed for the Technology Applications Program Office (TAPO) of the U.S. Army Special Operations …

Using the Architecture Tradeoff Analysis Method to Evaluate a Wargame Simulation System: A Case Study

November 30, 2001 • technical note, by lawrence g. jones , anthony j. lattanze.

This report describes the application of the ATAM (Architecture Tradeoff Analysis Method) to a major wargaming simulation system.

Using the Architecture Tradeoff Analysis Method to Evaluate a Reference Architecture: A Case Study

May 31, 2000 • technical note, by brian p. gallagher.

This report describes the application of the ATAM (Architecture Tradeoff Analysis Method) to evaluate a reference architecture for ground-based command and control systems.

Using Quality Attribute Workshops to Evaluate Architectural Design Approaches in a Major System Acquisition: A Case Study

June 30, 2000 • technical note, by john k. bergey , mario r. barbacci , william wood.

This report describes a series of Quality Attribute Workshops (QAWs) that were conducted on behalf of a government agency during its competitive acquisition of a complex, tactical, integrated command and …

Architecture Reconstruction to Support a Product Line Effort: Case Study

June 30, 2001 • technical note, by liam o'brien.

This report describes the architecture reconstruction process that was followed when the SEI performed architecture reconstructions on three small automotive motor systems.

Architecture Reconstruction Case Study

March 31, 2003 • technical note.

This report outlines an architecture reconstruction carried out at the SEI on a software system called VANISH, which was developed for prototyping visualizations.

Use of Quality Attribute Workshops (QAWs) in Source Selection for a DoD System Acquisition: A Case Study

May 31, 2002 • technical note, by john k. bergey , william wood.

This case study outlines how a DoD organization used architecture analysis and evaluation in a major system acquisition to reduce program risk.

• Case Studies
• Project delivery process

How to Build a Successful Solution Architecture: Case Study

What is solution architecture (in terms of software development)?

Software architecture design is a fundamental procedure for successful application development. It outlines and reasons the structure of the future app. Besides, solution architecture explains how all the application components will function together to achieve the desired result. 

Solution architecture is defined during the project discovery phase as it sets the cornerstones for the upcoming application development. It considers all the functional and nonfunctional requirements to configure the most suitable tech solution for your business. Besides the current state of art, a well designed app architecture should allow some flexibility for future scaling and updates.   

With all said above, it’s necessary to get the application architecture right before moving to the development. Architecture redesign is an extreme measure as it brings fundamental changes to the app which modify the IT infrastructure , possibly tech stack , features performance, etc., and requires high time and cost investment. 

In this article you will find the practices we use at Apiko to successfully design software architecture. Moreover, here’s our website architecture example within the cloud architecture case study. Ready? Let’s begin!

Discover the secret to uninterrupted IT system excellence with Apiko's AWS Infrastructure Support Service. Say goodbye to downtime worries, poor user experiences, and unsatisfied clients.

• 🔍 Free Infrastructure Audit: Assess your infrastructure for improvements across architecture, code, monitoring, security, and more.
• 🚀 Monthly Subscription Plan: Gain full control with continuous infrastructure audits, emergency support, and 24/7 issue resolution (starting at $300/month).
• 🔧 On-Demand DevOps Work: Access expert assistance at $60/hour.

What defines a successful solution architecture?

• Usability : Achieve maximal accordance between the solution architecture and application functionality that it enables, and future app users’ and stakeholders’ needs and requirements. 
• Performance : Determine and allocate the right amount of computing resources that is necessary and enough to ensure flawless app performance and smooth user experience.
• Cost efficiency : Define the level of app quality and performance which will be enough to satisfy your business needs. We clarify this data during the project discovery phase and summarize it in a form of app functional and nonfunctional requirements. Most often it’s possible to achieve a higher level of performance at a higher cost, so there’s a need to find the middle ground.   
• Reliability : Ensure that the application functions as it’s expected to at all times. 
• Security : Implement the protection mechanisms to prevent any data leakage and secure the application from possible malware attacks or other destructive activities.  
• Robustness for future updates and scaling : Both the business processes the application is built for and the technologies it is built with evolve with time. The overall app performance should not be affected by
• the growing number of users
• adding new app functionality  
• features updates
• updates of any of the technologies the app is built with, etc.

Of course, it’s impossible to foresee all the innovations a solution may face, but it will be easier to implement them when the architecture is robust. 

• Simplicity : Aim for the simplest solution that will satisfy all of the above-mentioned criteria. Don’t get it wrong: if there are simpler solutions, but they will obviously lead to technical debt, they should be omitted. Just avoid extra architecture complexity when there is no need for it. 

How to reach these criteria?

Follow the best practices . When it comes to developing cloud architecture, we refer to AWS best practices to create a well-architected solution. 

Collaborate tightly with the development team to get a better understanding of the application logic. Analyze the business needs and requirements to come up with the best app architecture.

Pick the proven technologies . New tools emerge nearly on a daily basis, and their functionality often looks very promising. However, many of them get replaced with the newer ones or simply vanish with nearly the same speed. Pay attention to the size of the professional community around a certain technology, and the time since it’s been launched and successfully used. The higher these numbers are, the more certain is the future support of this technology.   

Finding balance between a performant infrastructure and cost efficiency is one of the most challenging parts of solution architecture design. Software architecture for different projects includes different number of variable components and there is no one-fits-all solution.

What types of software architecture are there?

Based on the fundamental structure and resulting application properties, software architecture can be divided into two types: microservices and monolithic architecture .

Monolithic approach consists in building the application as a single functional unit with tight coupling of its components. As a rule, it’s perfect for smaller projects, as it enables their straightforward and transparent functioning without extra complexity. 

While implementing broad solutions may be too much to handle with a single monolithic codebase, microservices provide the required modularity. Loosely coupled components often have their own databases and function as relatively independent units. This means that you can update or modify any of them without having to worry about the overall app performance. 

For even more decoupled microservices and reduced dependencies between them, one can use event-driven architecture . Some popular platforms to implement it are SQS and Kafka .

You can find more details and tips on how to choose one of these architecture types in our article Software Architecture Types: Monolith vs Microservices .

Depending on the location of computing resources we can define cloud architecture , architecture configured on on-premises servers , and hybrid architecture . While the latter one allows the owner physical access to the hardware, it requires an in-house team of software developers for its support and maintenance. In addition, app scalability depends on the hardware resources available. 

Cloud-based architecture does not allow physical access to the servers. However, it eliminates the above-mentioned challenges by offering monitoring and testing automation, unlimited scalability potential, professional support services and more. No wonder why it’s the commonly used solution with a still growing popularity. 

See the chart showing annual end-user expenses for public cloud services worldwide over a few past years.

Source: Statista.com

Hybrid architecture consists in using both on-premises and cloud resources. Most often it’s used to conform to certain policies and regulations, e.g. when some data must be stored on premises only, or to avoid possible latency when processing data from the cloud, etc.

None of these architecture solutions is a universally best choice for every project. It’s necessary to take into account the software peculiarities to select which approach will be the most suitable match.

What types of cloud architecture are there?

Sometimes it is necessary to have your own data center or a number of local servers. However, cloud architecture suits the majority of solutions, so let’s get familiar with its types.

Public cloud architecture is a rather cost-efficient solution when the computing resources belong to and are managed by a cloud service provider, e.g. AWS or Google. Cloud services are delivered using a multi-tenant approach, and provide customers with the capabilities required for their software projects.  

Private cloud architecture is configured on a cloud that belongs to and is managed by the software owner, i.e. is private. For example, it may consist of numerous company's on-premises servers and data centers which do not necessarily have to be located in one place. As a rule, managing a private cloud is more costly than using cloud providers services. However, it allows maximal flexibility, implementing advanced security solutions, and making the most of the cloud resources available.   

Multi-cloud architecture combines the computational resources of multiple public clouds and on-premises servers. Such an approach allows avoiding a dependence on a particular cloud service provider, and a possible cost reduction. It also provides flexibility to pick the services most suitable for implementation of different app features or microservices.

Hybrid architecture is often referred to as hybrid cloud architecture . It’s a subtype of multi-cloud architecture and we’ve described it in the previous paragraph.

How do we design solution architecture at Apiko? [Cloud architecture case study]

Every application is built to match some business requirements. Designing the underlying server architecture is like mimicking the app behavior. It highly depends on the app purpose and functionality, security measures, governmental regulations and restrictions, etc. So, the solution architect tightly collaborates with the development team to find out these details.

What are the stages of cloud architecture development?  

• Before we begin building cloud architecture we need to consider
• business drivers
• functional + nonfunctional requirements 
• constraints 
• necessity to fit into the existing environment (ecosystem) where the project will be used
• flexibility.
• Then we choose a suitable type of app architecture: monolith or microservices. After it, we will be able to pick the computing resources. For example, for microservice architecture, we can choose AWS Lambdas or Elastic Container Service with the serverless approach , or pick the appropriate servers for high computing or data processing apps.
• Consider what type of cloud services we will use in our application, so that AWS Solution Architect can start configuring appropriate access policies, roles and design networks for the app.
• Configure the production-ready environment. Collaborate more with application developers to have a better vision of the application logic and how it should perform. Pay attention to what queries need to be cached, and how.
• If there is no cache, the website can be slow and low performant.
• If infrastructure caches unnecessary queries or files, it may lead to errors in website usage. 
• Implement initial DoS protection, like AWS WAF , to handle suspicious requests. Without such protection the software can crash and be unable to respond to any request. The worst cases may result in personal data leakage. Some common website attacks include
• Denial-of-Service (DoS) / Distributed * Denial-of-service (DDoS)
• Web Defacement Attack 
• SSH Brute Force Attack 
• Cross-site scripting (XSS)
• Directory Traversal
• MITM Attack
• HTTP Response Splitting Attack
• Test the production-ready environment with load-testing tools, e.g. Gatling , to see how performant the infrastructure is in terms of scalability and efficiency. Load testing can also show us how the application performs during POST or GET requests, and what queries are slowing down the application. After that, we can decide what should be fixed, or configured for the production environment. 
• After the architecture is designed, it is used by the development team to see the key components of the underlying infrastructure.

What does Apiko website architecture look like?

You can see the Apiko website architecture diagram below.

We have picked S3 as a static hosting for our website which saved us from configuring additional servers.

ECS is a container service managed by AWS which provides all the computing power. It’s a cost-effective solution, as it’s easy to scale it up or down whenever needed.

We’ve picked S3 Bucket as an object oriented storage for private or public files. 

CloudFront has been chosen for caching.

Is a new solution architecture necessary for every project?

You don’t need to build new solution architecture for relatively minor projects designed to work within an environment similar to an already existing one. Those can be  

• small modules 
• landing pages 
• content updates and minor changes to an existing application, etc.

Let’s sum it up!

It’s a must to design software architecture correctly before the very beginning of your project development. Poor architecture design always affects performance and overall user experience. For example, it can be caused by wrong server CPU or RAM configuration, or caching of the wrong queries, etc.

At Apiko, AWS-certified solution architects collaborate tightly with the development team to set the basis for well-reasoned decision making regarding the solution architecture. Even the perfect underlying infrastructure can’t really perform at its best if the application is not optimized, or is poorly designed (doesn’t use caching, has unoptimized database queries. etc.), and vice versa. Active communication with the software engineers helps us reach a much-needed balance between designing the perfect application architecture and its underlying infrastructure configuration.

We use the best practices and proven technologies to minimize any risks and future-proof software solutions. Do not hesitate to reach out if you need any assistance, have questions, or would like to discuss your ideas with us!

Might be interesting for you

AI SQL Query Optimization for Increased Accuracy of AI Assistants [Case Study]

UI and UX Optimization for Efficient Software Modernization [Case Study]

Get full access to Software Architecture: A Case Based Approach and 60K+ other titles, with a free 10-day trial of O'Reilly.

There are also live events, courses curated by job role, and more.

Software Architecture: A Case Based Approach

Read it now on the O’Reilly learning platform with a 10-day free trial.

O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Book description

The book discusses the discipline of Software Architecture using real-world case studies and poses pertinent questions that arouse objective thinking. With the help of case studies and in-depth analyses, it delves into the core issues and challenges of software architecture.

Table of contents

• About Case Study Methodology
• How Did Each Case Study Come Up?
• Organization of the Book
• About Fact-Tree
• Acknowledgements
• About the Author
• The Rise and Fall of Netscape (or the Browser War 1994–1999)
• The Growing Demands on Software Development
• What Is Software Architecture?
• The Importance of Software Architecture
• Role of a Software Architect
• Component-Based Development (CBD)
• Component-Based Software Engineering (CBSE)
• Commercial Off-the-Shelf (COTS) Systems
• Architectural View
• Enterprise Architecture
• Systems architecture
• Software Architecture
• Technical Architecture
• Data Architecture
• Reference Architecture
• Product Line Architecture
• Architectural Drivers
• The Zachman Framework
• Phase A: Architecture Vision
• Phase B: Business Architecture
• Phase C: Information System Architecture
• Phase D: Technology Architecture
• Phase E: Opportunities and Solutions
• Phase F: Migration Planning
• Phase G: Implementation Governance
• Phase H: Architecture Change Management
• The 4+1 View Model
• Viewpoint Languages: Notations
• Rational Unified Process (RUP)
• Architectural Styles or Architectural Patterns
• Pipes and Filters
• Layered Abstract Machines
• N-Tier Architectures
• Distributed Peer-to-Peer Systems
• Anti-patterns
• Polya’s How to Solve It—A Problem-Solving Guide
• Systems Principles
• Systems Methodology of Problem Solving
• Further Reading
• Communication
• Understanding the Domain Requirements
• Developing (Selecting) the Architecture
• Representing and Communicating the Architecture
• Analysing or Evaluating the Architecture
• Objectives of Use Case Analysis
• Use Case Analysis Activity
• Architectural Requirements
• System Structuring or Designing the Architecture
• Architecture Review and Validation
• Use Case: Enroll Insured
• Use Case: Get Insured
• Use Case: Check Eligibility
• Use Case: Change Insured
• Use Case: Calculate Premium
• Use Case: Pay Online
• Use Case: Manage Insured
• Use Case: Issue Letters
• Use Case: Generate Reports
• Use Case: Manage Billing and Accounts
• Use Case: Manage Users
• Use Case: Login
• Structure Various Sub-systems to Come Up with Initial Architecture
• Role of a Client
• Role of MidAlliance
• Conclusions
• Best Practices and Key Lessons from the Case Study
• Software Architecture Goals and Drivers
• MVC Architecture
• Re-factoring
• Performance Objectives
• Performance Improvement
• Understanding Architecture
• Identifying Key Scenarios
• Asking questions
• Performance modelling
• Using architecture anti-patterns
• Performance review of the system
• Refining the System
• Use case view
• Logical view
• Process view
• Implementation view
• Deployment view
• Step 2: Prepare for the Evaluation
• Evaluating performance
• Step 4: Reflect the Evaluation
• What Is Architectural Evaluation?
• Why Should Architecture Be Evaluated and Reviewed?
• When to Evaluate and Review?
• Who Should Evaluate and Review?
• What Should Be Reviewed?
• How to Review Architectures?
• Techniques for Evaluation and Review
• The review method
• Scenario-based Review Methods
• Which Method to Use?
• Prerequisites and inputs
• Steps in the evaluation process
• Step 1—Develop scenarios
• Step 2—Describe architecture(s)
• Step 3—Classify and prioritize scenarios
• Step 4—Individually evaluate indirect scenarios
• Step 5—Assess scenario interaction
• Step 6—Create an overall evaluation
• Increasing the effectiveness of your review
• Generate a quality attribute utility tree
• Use quality attribute taxonomies
• Identify risks, sensitivity points and trade-offs
• What Is Design?
• Design Notations
• The Design Process
• Moving from Architecture to Design
• Step 1: Defining System Context
• Step 2: Identifying the Modules
• Step 3: Describing the Components and Connectors
• Characteristics of a Good Design
• Use Case Specification
• Sequence Diagrams
• Class Diagrams
• Why Component-based Development?
• Commercial-off-the-Shelf Components
• Open Systems
• Netscape browser rewrite
• Microsoft Vista (earlier code named as Longhorn)
• Firefox browser
• How Different is the CBD Approach?
• Developer (Producer) and Consumer Perspectives on CBD
• Why CBD—Cost and Use
• Success Factors of CBD
• Inconsistent Component Integration
• How to avoid mismatches
• What to do in case of a mismatch
• Techniques for repairing mismatched interfaces
• Next-Generation Systems
• Reuse Maturity Levels Needed in an Organization
• Need for frequent updates
• Provide secured environment
• Drive for reduced total cost of operation
• Challenges in Implementing SOA
• Web Services
• SOA and Web Services
• Service-Oriented Grids
• Enterprise Service Bus
• Business Trends
• Codification and Socialization
• Handling Quality Attributes
• Architectural Automation
• Architectural Responsibility
• Accidental versus Intentional Architects
• Domain Versatility and Adaptability
• Technology Dependency
• Inter-disciplinary Architecture
• Criticality of Serviceability
• Criticality of Adaptability
• Criticality of Productivity
• Software Service Lines or Service Line Architectures

Product information

• Title: Software Architecture: A Case Based Approach
• Author(s): Vasudeva Varma
• Release date: March 2009
• Publisher(s): Pearson India
• ISBN: 9788131707494

You might also like

Complex enterprise architecture: a new adaptive systems approach.

by John D. McDowall

Implement successful and cost-effective enterprise architecture projects. This book provides a new approach to developing enterprise …

Software Requirements Using the Unified Process: A Practical Approach

by Daniel R. Windle, L. Rene Abreo

Effective requirements development: An end-to-end process that works. How to build requirements that can easily be …

Requirements Modelling and Specification for Service Oriented Architecture

by Ian Graham

Many software developers often confuse requirements engineering with software specification and, as a result, build unusable …

Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures

by Hassan Gomaa

"Designing Software Product Lines with UML is well-written, informative, and addresses a very important topic. It …

Don’t leave empty-handed

Get Mark Richards’s Software Architecture Patterns ebook to better understand how to design components—and how they should interact.

It’s yours, free.

Check it out now on O’Reilly

Dive in for free with a 10-day trial of the O’Reilly learning platform—then explore all the other resources our members count on to build skills and solve problems every day.

22 August 2024: Due to technical disruption, we are experiencing some delays to publication. We are working to restore services and apologise for the inconvenience. For further updates please visit our website: https://www.cambridge.org/universitypress/about-us/news-and-blogs/cambridge-university-press-publishing-update-following-technical-disruption

We use cookies to distinguish you from other users and to provide you with a better experience on our websites. Close this message to accept cookies or find out how to manage your cookie settings .

Login Alert

• > Software Modeling and Design
• > Component-Based Software Architecture Case Study

Book contents

• Frontmatter
• Annotated Table of Contents
• Acknowledgments
• PART I Overview
• PART II Software Modeling
• PART III Architectural Design
• PART IV Case Studies
• 21 Client/Server Software Architecture Case Study
• 22 Service-Oriented Architecture Case Study
• 23 Component-Based Software Architecture Case Study
• 24 Real-Time Software Architecture Case Study
• Appendix A Catalog of Software Architectural Patterns
• Appendix B Teaching Considerations
• Answers to Exercises
• Bibliography

23 - Component-Based Software Architecture Case Study

from PART IV - Case Studies

Published online by Cambridge University Press:  05 June 2012

This chapter describes how the COMET software modeling and architectural design method is applied to the design of a component-based software architecture: an Emergency Monitoring System.

The problem description is given in Section 23.1. Section 23.2 describes the use case model for the Emergency Monitoring System. Section 23.3 describes the Emergency Monitoring System static model, covering static modeling of both the system context and entity classes. Section 23.4 describes dynamic modeling, in which communication diagrams are developed for each of the use cases. Section 23.5 describes the design model for the Emergency Monitoring System, which is designed as a layered architecture based on the Layers of Abstraction pattern combined with the client/service pattern and several architectural communication patterns. Section 23.6 describes software component deployment.

PROBLEM DESCRIPTION

An Emergency Monitoring System consists of several remote monitoring systems and monitoring sensors that provide sensor input to the system. The status of the external environment is monitored with a variety of sensors. Some of these sensors are attached to remote monitoring systems, which send regular status input that is stored at a monitoring service. In addition, from the sensor information, alarms are generated concerning undesirable situations in the external environment that require human intervention. Alarms are stored at an alarm service. Monitoring operators view the status of the different sensors and view and update alarm conditions.

USE CASE MODELING

This section describes the use case model for the Emergency Monitoring System. From the problem description, three actors are determined.

Access options

Save book to kindle.

To save this book to your Kindle, first ensure [email protected] is added to your Approved Personal Document E-mail List under your Personal Document Settings on the Manage Your Content and Devices page of your Amazon account. Then enter the ‘name’ part of your Kindle email address below. Find out more about saving to your Kindle .

Note you can select to save to either the @free.kindle.com or @kindle.com variations. ‘@free.kindle.com’ emails are free but can only be saved to your device when it is connected to wi-fi. ‘@kindle.com’ emails can be delivered even when you are not connected to wi-fi, but note that service fees apply.

Find out more about the Kindle Personal Document Service .

• Component-Based Software Architecture Case Study
• Hassan Gomaa , George Mason University, Virginia
• Book: Software Modeling and Design
• Online publication: 05 June 2012
• Chapter DOI: https://doi.org/10.1017/CBO9780511779183.025

Save book to Dropbox

To save content items to your account, please confirm that you agree to abide by our usage policies. If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account. Find out more about saving content to Dropbox .

Save book to Google Drive

To save content items to your account, please confirm that you agree to abide by our usage policies. If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account. Find out more about saving content to Google Drive .

How to Learn Software Design and Architecture - a Roadmap

This article is a summary of what I'm writing about in my newest project, solidbook.io - The Handbook to Software Design and Architecture with TypeScript . Check it out it you like this post.

It's crazy to me to consider the fact that Facebook was once an empty text file on someone's computer.

This past year, I've been going hard in software design and architecture, Domain-Driven Design , and writing a book on it, and I wanted to take a moment to try to piece it together into something useful I could share with the community.

Here's my roadmap for how to learn software design and architecture.

I've broken it down into two artifacts: the stack and the map .

Similar to the OSI Model in networking, each layer builds on top of the foundation of the previous one.

While I think the stack is good to see the bigger picture of how everything works together, the map is a little bit more detailed (and inspired by the web developer roadmap ) and as a result, I think it's more useful.

Here it is below! To fork the repo, read my detailed write-up and download it in high-res, click here .

Stage 1: Clean code

The very first step towards creating long-lasting software is figuring out how to write clean code .

Clean code is code that is easy to understand and change. At the low-level, this manifests in a few design choices like:

• being consistent
• preferring meaningful variable, method and class names over writing comments
• ensuring code is indented and spaced properly
• ensuring all of the tests can run
• writing pure functions with no side effects
• not passing null

Writing clean code is incredibly important.

Think of it like a game of jenga.

In order to keep the structure of our project stable over time, things like indentation, small classes and methods, and meaningful names, pay off a lot in the long run.

The best resource to learn how to write clean code is Uncle Bob's book, " Clean Code ".

Stage 2: Programming Paradigms

Now that we're writing readable code that's easy to maintain, it would be a good idea to really understand the 3 major programming paradigms and the way they influence how we write code.

In Uncle Bob's book, " Clean Architecture ", he brings attention to the fact that:

• Object-Oriented Programming is the tool best suited for defining how we cross architectural boundaries with polymorhpism and plugins
• Functional programming is the tool we use to push data to the boundaries of our applications
• and Structured programming is the tool we use to write algorithms

This implies that effective software uses a hybrid all 3 programming paradigms styles at different times.

While you could take a strictly functional or strictly object-oriented approach to writing code, understanding where each excels will improve the quality of your designs.

If all you have is a hammer, everything seems like a nail.

For functional programming , check out:

• Professor Frisby's Mostly Adequate Guide to Functional Programming
• Domain Modeling Made Functional

Stage 3: Object-Oriented Programming

It's important to know how each of the paradigms work and how they urge you to structure the code within them, but with respect to architecture, Object-Oriented Programming is the clear tool for the job .

Not only does Object-Oriented programming enable us to create a plugin architecture and build flexibility into our projects; OOP comes with the 4 principles of OOP (encapsulation, inheritance, polymorhism, and abstraction) that help us create rich domain models .

Most developers learning Object-Oriented Programming never get to this part: learning how to create a software implementation of the problem domain , and locating it in the center of a layered web app.

Functional programming can seem like the means to all ends in this scenario, but I'd recommend getting acquainted with model-driven design and Domain-Driven Design to understand the bigger picture on how object-modelers are able to encapsulate an entire business in a zero-dependency domain model.

Why is that a huge deal?

It's huge because if you can create a mental-model of a business, you can create a software implementation of that business.

Stage 4: Design Principles

At this point, you're understanding that Object-Oriented Programming is very useful for encapsulating rich domain models and solving the 3rd type of "Hard Software Problems"- Complex Domains .

But OOP can introduce some design challenges.

When should I use composition?

When should I use inheritance?

When should I use an abstract class?

Design principles are really well-established and battle-tested object-oriented best practices that you use as railguards.

Some examples of common design principles you should familiarize yourself with are:

• Composition over inheritance
• Encapsulate what varies
• Program against abstractions, not concretions
• The hollywood principle: "Don't call us, we'll call you"
• The SOLID principles , especially the Single responsibility principle
• DRY (Do Not Repeat Yourself)
• YAGNI (You Aren't Gonna Need It)

Make sure to come to your own conclusions, though. Don't just follow what someone else says you should do. Make sure that it makes sense to you.

Stage 5: Design Patterns

Just about every problem in software has been categorized and solved already. We call these patterns: design patterns, actually.

There are 3 categories of design patterns: creational , structural , and behaviour .

Creational patterns are patterns that control how objects are created.

Examples of creational patterns include:

• The Singleton pattern , for ensuring only a single instance of a class can exist
• The Abstract Factory pattern , for creating an instance of several families of classes
• The Prototype pattern , for starting out with an instance that is cloned from an existing one

Structural patterns are patterns that simplify how we define relationships between components.

Examples of structural design patterns include:

• The Adapter pattern , for creating an interface to enable classes that normally can't work together, to work together.
• The Bridge pattern , for splitting a class that should actually be one or more, into a set of classes that belong to a hierarchy, enabling the implementations to be developed independently of each other.
• The Decorator pattern , for adding responsibilities to objects dynamically.

Behavioural

Behavioural patterns are common patterns for facilitating elegant communication between objects.

Examples of behavioural patterns are:

• The Template pattern , for deferring the exact steps of an algorithm to a subclass.
• The Mediator pattern , for defining the exact communication channels allowed between classes.
• The Observer pattern , for enabling classes to subscribe to something of interest, and to be notified when a change occurred.

Design pattern criticisms

Design patterns are great and all, but sometimes they can an additional complexity to our designs. It's important to remember YAGNI and attempt to keep our designs as simple as possible. Only use design patterns when you're really sure you need them. You'll know when you will.

If we know what each of these patterns are, when to use them, and when to not even bother using them, we're in good shape to begin to understand how to architect larger systems.

The reason behind that is because architectural patterns are just design patterns blown-up in scale to the high-level , where design patterns are low-level implementations (closer to classes and functions).

Refactoring Guru - Design Patterns

Stage 6: Architectural Principles

Now we're at a higher level of thinking beyond the class level.

We now understand that the decisions we make towards organzing and building relationships between components at the high-level and the low-level, will have a significant impact on the maintainability, flexibility, and testability of our project.

Learn the guiding principles that helps you build in the flexibility that your codebase needs in order to be able to react to new features and requirements, with as little effort as possible.

Here's what I'd recommend learning right off the bat:

• Component design principles: The Stable Abstraction Principle , The Stable Dependency Principle , and The Acyclic Dependency Principle, for how to organize components, their dependencies, when to couple them, and the implications of accidentally creating dependency cycles and relying on unstable components.
• Policy vs. Detail , for understanding how to separate the rules of your application from the implementation details.
• Boundaries, and how to identify the subdomains that the features of your application belongs within.

Uncle Bob discovered and originally documented many of these principles, so the best resource to learn about this is again, " Clean Architecture ".

Stage 7: Architectural Styles

Architecture is about the stuff that matters.

It's about identifying what a system needs in order for it to be successful, and then stacking the odds of success by choosing the architecture that best fits the requirements.

For example, a system that has a lot of business logic complexity would benefit from using a layered architecture to encapsulate that complexity.

A system like Uber needs to be able to handle a lot of real time-events at once and update drivers' locations, so publish-subscribe style architecture might be most effective.

I'll repeat myself here because it's important to note that the 3 categories of architectural styles are similar to the 3 categories of design patterns, because architectural styles are design patterns at the high-level .

Projects with varying levels of components and wide-ranging functionality will either benefit or suffer from adopting a structural architecture.

Here are a few examples:

• Component-based architectures emphasize separation of concerns between the individual components within a system. Think Google for a sec. Consider how many applications they have within their enterprise (Google Docs, Google Drive, Google Maps, etc). For platforms with lots of functionality, component-based architectures divide the concerns into loosely coupled independent components. This is a horizontal separation.
• Monolithic means that the application is combined into a single platform or program, deployed altogether. Note: You can have a component-based AND monolithic architecture if you separate your applications properly, yet deploy it all as one piece .
• Layered architectures separate the concerns vertically by cutting software into infrastructure, application, and domain layers.

An example of cutting the concerns of an application vertically by using a layered architecture. Read here for more information on how to do this.

Depending on your project, messaging might be a really important component to the success of the system. For projects like this, message-based architectures build on top of functional programming principles and behavioural design patterns like the observer pattern.

Here are a few examples of message-based architectural styles:

• Event-Driven architectures view all signficant changes to state as events. For example, within a vinyl-trading app , a offer's state might change from "pending" to "accepted" when both parties agreee on the trade.
• Publish-subscribe architectures build on top of the Observer design pattern by making it the primary communication method between the system itself, end-users / clients, and others systems and components.

Distributed

A distributed architecture simply means that the components of the system are deployed separately and operate by communicating over a network protocol. Distributed systems can be very effective for scaling throughput, scaling teams, and delegating (potentially expensive tasks or) responsibility to other components.

A few examples of distributed architectural styles are:

• Client-server architecture. One of the most common architectures, where we divide the work to be done between the client (presentation) and the server (business logic).
• Peer-to-peer architectures distribute application-layer tasks between equally-privileged participants, forming a peer-to-peer network.

Stage 8: Architectural Patterns

Architectural patterns explain in greater tactical detail how to actually implement one of those architectural styles .

Here are a couple of examples of architectural patterns and the styles that they inherit from:

• Domain-Driven Design is an approach to software development against really complex problem domains. For DDD to be most successful, we need to implement a layered architecture in order to separate the concerns of a domain model from the infrastrural details that makes the application actually run, like databases, webservers, caches, etc.
• Model-View Controller is probably the most well-known architectural pattern for developing user interface-based applications. It works by dividing the app into 3 components: model, view, and controller. MVC is incredibly useful when you're first starting out, and it helps you piggyback towards other architectures, but there hit's a point when we realize MVC isn't enough for problems with lots of business logic.
• Event sourcing is a functional approach where we store only the transactions, and never the state. If we ever need the state, we can apply all the transactions from the beginning of time.

Stage 9: Enterprise patterns

Any architectural pattern you choose will introduce a number of constructs and technical jargon to familiarize yourself with and decide on whether it's worth the effort to use or not.

Taking an example that many of us know, in MVC , the view holds all the presentation layer code, the controller is translates commands and queries from the view into requests that are handled by the model and returned by the controller .

Where in the Model (M) do we handle these things?:

• validation logic
• invariant rules
• domain events
• complex queries
• and business logic

If we simply use an ORM (object-relational mapper) like Sequelize or TypeORM as the model , all that important stuff to gets left to interpretation on where it should go, and it finds itself in some unspecified layer between (what should be a rich) model and the controller .

Taken from "3.1 - Slim (Logic-less) models" in solidbook.io .

If there's something I've learned so far in my journey going beyond MVC, it's that there is a construct for everything .

For each of those things that MVC fails to address, there exist other enterprise patterns to solve them. For example:

• Entities describe models that have an identity.
• Value Objects are models that have no identity, and can be used in order to encapsulate validation logic.
• Domain Events are events that signify some relevant business event occurring, and can be subscribed to from other components.

Depending on the architectural style you've chosen, there are going to be a ton of other enterprise patterns for you to learn in order to implement that pattern to it's fullest potential.

Integration patterns

Once your application is up and running, as you get more and more users, you might run into performance issues. API calls might take a long time, servers might crash from being overloaded with requests, etc. In order to solve these problems, you might read about integrating things like message queues or caches in order to improve performance.

This is probably the most challenging stuff: scaling, audits, and performance .

Designing a system for scale can be incredibly challenging. It requires a deep understanding of the limitations of each component within the architecture, and a plan of action for how to mitigate stress on your architecture and continue to serve requests in high-traffic situations.

The need also the need to audit what's going on in your application. Large enterprise companies need to be able to perform audits in order to identify potential security issues, understand how users are using their applications, and have a log of everything that's ever happened.

This can be challenging to implement, but common architectures end up looking event-based and build upon a wide range of software and system design concepts, principles, and practices like Event Storming, DDD, CQRS (command query response segregation), and Event Sourcing.

I hope that was useful to you!

Let me know if you have any suggestions or questions.

Fork it on GitHub

Read the book on software design & architecture

Read the write-up

khalilstemmler.com - I teach Advanced TypeScript & Node.js best practices for large-scale applications and how to write flexible, maintainable software.

Hey! I'm Khalil. I enjoy teaching Advanced TypeScript best practices for large-scale applications and how to write flexible, maintainable software.

If you read this far, thank the author to show them you care. Say Thanks

Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. Get started