Visualise, document and explore your software architecture
This book is 80% complete
Last updated on 2019-03-05
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
Bundles that include this book
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
-
1. We have a failure to communicate
-
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
-
11. Software documentation as a guidebook
-
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 model-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
-
25. Sketches, diagrams, models and tooling
- 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
Free Updates. Free App. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers), EPUB (for phones and tablets), MOBI (for Kindle) and in the free Leanpub App (for Mac, Windows, iOS and Android). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
