techtribes.je - containers

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.

techtribes.je - containers diagram

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.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.



Re: techtribes.je - containers

What do you do if you have a "container within a container?" For example, I have an in-memory data store deployed as a war in my Glassfish server. In the container view, would you represent the internal container inside of the Glassfish container or separate since it is actually a separate container?

Re: techtribes.je - containers

The easiest way to think about this is to look at how you're using the in-memory data store. If the data store is a separate WAR file and you're connecting to it using a network protocol (even via a localhost address), I would draw it as a separate container. From a logical point of view, it *is* a separate container - it's just that you're deploying everything on a single Glassfish server. If the data store is part of your app (e.g. you're including a JAR file in a WAR file that you're creating), then perhaps it's better to show it as a component within your app. Which data store are you using?

Re: techtribes.je - containers

It's actually a Sesame triple store, and the first option you mention matches what we are doing. We deploy it as a war and treat it as a remote repository. Thanks Adam

Add a comment Send a TrackBack