Visualise, document and explore your software architecture
Visualise, document and explore your software architecture
$20.00
Minimum price
$25.00
Suggested price
Visualise, document and explore your software architecture

This book is 80% complete

Last updated on 2018-01-31

About the Book

This book focusses on the visual communication and documentation of software architecture, based upon a collection of ideas and techniques that thousands of people across the world have found useful. The core of this is my C4 software architecture model and the software guidebook. You'll also find discussion about notation, the various uses for diagrams, the value of creating a model and tooling.

This book was formerly called "The Art of Visualising Software Architecture", and now additionally includes information about documentation.

About the Author

Simon Brown
Simon Brown

Simon is an independent software development consultant specializing in software architecture; specifically technical leadership, communication, and lightweight, pragmatic approaches to software architecture. Simon is the author of "Software Architecture for Developers", a developer-friendly guide to software architecture, technical leadership, the balance with agility and communicating software architecture with sketches, diagrams, and models. He is also the creator of the C4 model and the founder of Structurizr, a collection of tooling to help teams visualise, document and explore their software architecture.

Bundles that include this book

Technical leadership and the balance with agility
Visualise, document and explore your software architecture
2 Books
$50.00
Suggested Price
$25.00
Bundle Price

Table of Contents

  •  
    • About the book
    • About the author
  • I Visualise
    • 1. We have a failure to communicate
      • 1.1 What happened to SSADM, RUP, UML, etc?
      • 1.2 A lightweight approach
      • 1.3 Moving fast requires good communication
      • 1.4 Where do we start?
      • 1.5 Some examples
      • 1.6 Common problems
      • 1.7 The hidden assumptions of diagrams
    • 2. A shared vocabulary
      • 2.1 Common abstractions over a common notation
      • 2.2 Static structure
      • 2.3 Software systems
      • 2.4 Containers
      • 2.5 Components
      • 2.6 Components vs classes
      • 2.7 Non-OO components
      • 2.8 Modules and subsystems?
      • 2.9 Microservices?
      • 2.10 Platforms, frameworks and libraries?
      • 2.11 Create your own shared vocabulary
    • 3. The C4 model
      • 3.1 Shneiderman’s mantra
    • 4. Level 1: Context diagram
      • 4.1 Intent
      • 4.2 Structure
      • 4.3 Elements
      • 4.4 Interactions
      • 4.5 Motivation
      • 4.6 Audience
      • 4.7 Required or optional?
    • 5. Level 2: Container diagram
      • 5.1 Intent
      • 5.2 Structure
      • 5.3 Elements
      • 5.4 Interactions
      • 5.5 Motivation
      • 5.6 Audience
      • 5.7 Required or optional?
    • 6. Level 3: Component diagram
      • 6.1 Intent
      • 6.2 Structure
      • 6.3 Elements
      • 6.4 Interactions
      • 6.5 Motivation
      • 6.6 Audience
      • 6.7 Required or optional?
    • 7. Level 4: Class diagram
      • 7.1 Intent
      • 7.2 Structure
      • 7.3 Motivation
      • 7.4 Audience
      • 7.5 Required or optional?
    • 8. Notation
      • 8.1 Titles
      • 8.2 Keys and legends
      • 8.3 Elements
      • 8.4 Lines
      • 8.5 Layout
      • 8.6 Orientation
      • 8.7 Acronyms
      • 8.8 Quality attributes
      • 8.9 Diagram scope
      • 8.10 Listen for questions
    • 9. Diagrams must reflect reality
      • 9.1 The model-code gap
      • 9.2 Technology details on diagrams
      • 9.3 Would you code it that way?
    • 10. Other diagrams
      • 10.1 Architectural view models
      • 10.2 Enterprise context
      • 10.3 User interface mockups and wireframes
      • 10.4 Business process and workflow
      • 10.5 Domain model
      • 10.6 Runtime and behaviour
      • 10.7 Infrastructure
      • 10.8 Deployment
      • 10.9 And more
  • II Document
    • 11. Software documentation as a guidebook
      • 11.1 The code doesn’t tell the whole story
      • 11.2 Our duty to deliver documentation
      • 11.3 Lightweight, supplementary documentation
      • 11.4 1. Maps
      • 11.5 2. Sights
      • 11.6 3. History and culture
      • 11.7 4. Practical information
      • 11.8 Describe what you can’t get from the code
      • 11.9 Product vs project documentation
      • 11.10 Keeping documentation up to date
      • 11.11 Documentation length
    • 12. Context
      • 12.1 Intent
      • 12.2 Structure
      • 12.3 Motivation
      • 12.4 Audience
      • 12.5 Required
    • 13. Functional Overview
      • 13.1 Intent
      • 13.2 Structure
      • 13.3 Motivation
      • 13.4 Audience
      • 13.5 Required
    • 14. Quality Attributes
      • 14.1 Intent
      • 14.2 Structure
      • 14.3 Motivation
      • 14.4 Audience
      • 14.5 Required
    • 15. Constraints
      • 15.1 Intent
      • 15.2 Structure
      • 15.3 Motivation
      • 15.4 Audience
      • 15.5 Required
    • 16. Principles
      • 16.1 Intent
      • 16.2 Structure
      • 16.3 Motivation
      • 16.4 Audience
      • 16.5 Required
    • 17. Software Architecture
      • 17.1 Intent
      • 17.2 Structure
      • 17.3 Motivation
      • 17.4 Audience
      • 17.5 Required
    • 18. Code
      • 18.1 Intent
      • 18.2 Structure
      • 18.3 Motivation
      • 18.4 Audience
      • 18.5 Required
    • 19. Data
      • 19.1 Intent
      • 19.2 Structure
      • 19.3 Motivation
      • 19.4 Audience
      • 19.5 Required
    • 20. Infrastructure Architecture
      • 20.1 Intent
      • 20.2 Structure
      • 20.3 Motivation
      • 20.4 Audience
      • 20.5 Required
    • 21. Deployment
      • 21.1 Intent
      • 21.2 Structure
      • 21.3 Motivation
      • 21.4 Audience
      • 21.5 Required
    • 22. Operation and Support
      • 22.1 Intent
      • 22.2 Structure
      • 22.3 Motivation
      • 22.4 Audience
      • 22.5 Required
    • 23. Development Environment
      • 23.1 Intent
      • 23.2 Structure
      • 23.3 Motivation
      • 23.4 Audience
      • 23.5 Required
    • 24. Decision Log
      • 24.1 Intent
      • 24.2 Structure
      • 24.3 Motivation
      • 24.4 Audience
      • 24.5 Required
  • III Tooling
    • 25. Sketches, diagrams, models and tooling
      • 25.1 Sketches
      • 25.2 Diagrams
      • 25.3 Models
      • 25.4 Reverse-engineering the software architecture model
      • 25.5 Architecture description languages
      • 25.6 Structurizr
      • 25.7 Minimise the mode-code gap
    • 26. The C4 model with other notations and tools
      • 26.1 Boxes and lines
      • 26.2 UML (with a modeling tool)
      • 26.3 UML (with PlantUML)
    • 27. Exploring your software architecture model
      • 27.1 Static structure
      • 27.2 Dependency maps
      • 27.3 Component size or complexity
      • 27.4 Other ways to explore
    • 28. Appendix A: Financial Risk System
      • 28.1 Background
      • 28.2 Functional Requirements
      • 28.3 Non-functional Requirements
  • Notes

The Leanpub 45-day 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms...

Write and Publish on Leanpub

Authors, publishers and universities use Leanpub to publish amazing in-progress and completed books and courses, just like this one. You can use Leanpub to write, publish and sell your book or course as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Learn more about writing on Leanpub