Webinar Recording: Software Architecture as Code
The recording of our webinar with Simon Brown, Software Architecture as Code,
is now available on JetBrains YouTube Channel, as well as select Q&A below.
Here are the slides used in the webinar and the code.
We’re still manually drawing software architecture diagrams in tools like Microsoft Visio. Furthermore, these diagrams often don’t reflect the implementation in code, and vice versa. This session with Simon Brown looks at why this happens and how to resolve the conflict between software architecture and code through the use of architecturally-evident coding styles and the representation of software architecture models as code.
01:28 – How do we communicate software architecture?
07:00 – Abstraction is about reducing detail
07:50 – Does your code reflect the abstractions you think about?
11:18 – Why not auto-generate the diagrams?
13:42 – The intersection of software architecture and code
14:08 – The C4 model
19:40 – A C4 example – techtribes.je
23:10 – The static model is about code
23:56 – Why isn’t the architecture in the code?
29:10 – Questions
32:10 – Software architecture as code demo with Structurizr
52:45 – Summary
53:40 – Questions
Select webinar questions and answers with Simon.
Q: How can Structurizr be used in a build system, can I install a local copy or will it be a (paired) SaaS?
A: I’m still undecided whether structurizr.com will be a free or paid service or, more likely, a combination of the two. My hope is that other people will build diagramming tools that operate on the same intermediate JSON format produced by the open source library. These could include wiki integrations, IDE plugins, etc.
Q: Could Structurizr generate XMI so that UML tools could import.
A: Yes. On my todo list is also an export to something like DOT for subsequent import into graphing tools.
Q: Can the tool also be used as easy as shown with Java Enterprise?
A: Yes, and somebody is planning to contribute a Java EE component finder to make this easier.
Q: Do we need a JSR for Components, Layers etc. to be introduced to Java?
A: I’m not sure, possibly. Information about the “architecture” is absent from most codebases, so this could in theory provide a standard way to address this issue in Java. It will be interesting to see what modularity in Java 9 brings.
Q: Does a .NET port exist? Or do you plan to produce one?
A: A partial C# port exists at https://github.com/wolfbyte/ArchitectureScript
Q: Does the ComponentFinder work with frameworks other than Spring, e.g. Guice?
A: At the moment there are component finders for Spring and my custom Structurizr annotations, as well as some that identify components based upon naming conventions (e.g. classes named *Service). There are plans for a Java EE version and anybody is welcome to contribute an implementation at https://github.com/structurizr/java
Q: It seems like your reduced tweet component mirrors an OSGi module. Is this on purpose?
A: You can think of my tweet component as a lightweight component, without any of the additional complexity, decoupling and other benefits that OSGi brings. But yes, structuring my code in this way allows me to explicitly consider and implement modularity at a level larger than a single Java class.
Q: Why don’t the diagrams use standard UML notation?
A: I personally don’t find that UML works well for describing software systems at the "architecture" level, plus UML doesn’t really support context diagrams that well. Also, based upon my experience, very few people seem to understand UML nowadays. SysML and ArchiMate are other possible notations. You can use UML to represent similar diagrams though, and if you’re interested in this I would recommend taking a look at this talk that Eoin Woods and I did at the "Software Architect 2014" conference in London.
Q: Each time you build does the diagrams loose their formatting of the box layout and arrangements?
A: No, you can copy layout information from the views in one workspace to those in another. Another possibility is automatic layout functionality, although I have no plans to build this myself.
Q: What about applying this approach to Desktop-class application? What components would you split it into besides the DB component?
A: The process is the same. A containers diagram would show your desktop application communicating with your database, and the components diagram for the desktop application would show how you’ve decomposed it into components, modules, services, layers, etc.
Q: What architect tools would you recommend along with an approach that you have just shared?
A: Some pens, paper and a whiteboard! In all seriousness, the lack of down-to-earth software architecture tooling is one of the reasons behind Structurizr.
Q: How do you keep diagrams up-to date?
A: This is one of the problems that I’m trying to solve, and it’s relatively straightforward if you integrate something like Structurizr with your automated build process.
Q: I see no reference to Domain-Driven Design in your approach. Why not?
A: In short, I don’t want to couple this way of thinking about a software system (my C4 model) to any particular design approach.
Simon Brown is an independent consultant and helps organisations to build better software by adopting a lightweight, pragmatic approach to software architecture. He is the creator of the C4 software architecture model and the author of “Software Architecture for Developers”, a developer-friendly guide to software architecture, technical leadership and the balance with agility.
Subscribe to IntelliJ IDEA Blog updates
