As a follow-up to my recent post called Aligning software architecture and code, this is the second in a series of short posts that will look at the code behind the techtribes.je website that I recently open sourced on GitHub. The posts will also show examples of some simple software architecture diagrams based upon the C4 approach (context, containers, components and classes) that is described in my Leanpub e-book called Software Architecture for Developers. There's also a short introduction on InfoQ called Agile Software Architecture Sketches and NoUML. Part 1 can be found at techtribes.je - context and I'll be talking about this at the Agile 2013 conference in Nashville, TN this week if you're attending.
High-level software architecture and technology choices
The high-level software architecture of techtribes.je comprises of a number of containers. By "container" I mean something like a web server, application server, desktop application, mobile app, database, file system, etc. Essentially, what I call a container is anything that can host code or data. The following diagram shows the logical containers that make up techtribes.je.
Put simply, techtribes.je is made up of an Apache Tomcat web server that provides users with information, and that information is kept up to date by a standalone content updater process. All data is stored either in a MySQL database, a MongoDB database or the file system. It's worth pointing out that this diagram says nothing about the number of physical instances of each container. For example, there could be a farm of web servers running against a MongoDB cluster, but this diagram doesn't show that level of information. Instead, I show physical instances, failover, clustering, etc on a separate deployment diagram. The containers diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices and how the containers communicate with one another. It's a simple, high-level technology focussed diagram that is useful for software developers and support/operations staff alike.
The next post will open up one of the containers and look at how it is decomposed into a number of components.