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.
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 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
-
25. Sketches, diagrams, models and tooling
- Notes
Bundles that include this book
About the Author
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.
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...
