⚡ TL;DR
- Monolith apps are modelled as a single ‘large’ deployable app and store in Level 2.
- Microservices are modelled as API service and database pairs in Level 2.
- Event-based entities like queues and topics can be modelled as containers (apps/stores) in Level 2 or as a tech choice on a connection.
- Domain-driven design concepts like domains, subdomains, and bounded context can be represented in IcePanel using a combination of Landscapes, Domains, and Groups.
Introduction
The C4 model is a lightweight and flexible framework for representing a variety of software architecture patterns, such as microservices, monoliths, event-driven, or domain-driven design. In this guide, we’ll explore some core patterns and how to model them in IcePanel. Let’s dive in!
Monolith application
A traditional monolith app contains business logic, interfaces, and databases in a single unit. Monoliths are deployed and maintained as a large codebase. To represent this in the C4 model, show the monolith as a single app and database in Level 2. Remember, a container is defined as an individually deployable/runnable object in the C4 model - the monolith is the deployable unit. To explain the internal components of the monolith, zoom in on the app to define the different modules or controllers in Level 3.
In this example, we have a monolithic e-commerce app. The Level 1 diagram contains a system representing the e-commerce platform (Online Boutique). At Level 2, we have a single app for the monolith and a store for the database. At Level 3 (of the app), we break it down to show the different components.
Level 1 — Context diagram
Level 2 — App/Container diagram
Level 3 — Component diagram
Microservices
In a microservice architecture, the app is divided into separate, independently deployable services that focus on different business capabilities. The services have distinct codebases and communicate with each other through APIs.
To model this in IcePanel, show the microservice as an app for the API and a store for the database. If you’d like to be more explicit about the API and store pairing, create a Group and assign the containers to it.
Going back to our example, we show the e-commerce platform as a single system in Level 1, just like in the monolith example. However, the Level 2 diagram will now have a collection of apps and stores for each microservice. Groups can optionally be added to show the microservice pairs clearly.
Level 1 — Context diagram (same as monolith example)
Level 2 — App/Container diagram
Event-driven
Message-based communication with queues and topics has become a popular architectural pattern for enabling decoupled systems to communicate with each other at scale. There are 2 recommended ways to model this in IcePanel.
Queues or topics as apps in Level 2
Represent the individual queues or topics as apps with connections going in and out to other objects. You can also represent them as stores (just make sure to be consistent in your usage). Avoid modelling a single message bus, which can lead to a ‘hub and spoke’ design. This hides the underlying relationships between the sender and receiver objects.
Queues/topics on connections
Alternatively, represent queues or topics as a tech choice on top of a connection. This method produces a much cleaner diagram but obfuscates the transport information as a tradeoff. There’s no right or wrong way to do this, but stay consistent in your method.
Domain-driven design
Domain-driven design (DDD) focuses on modelling software based on business goals and customer problems. The goal is to align code and architecture with business processes.
There are plenty of resources on DDD, so we won’t go into detail on the literature, but the key concepts to consider are domains, subdomains, and bounded context. It’s best to think of these as organizational constructs in the C4 model, as opposed to abstractions. Avoid trying to retrofit DDD into the C4 model abstractions - they’re different methodologies for different purposes.
These key domain-driven concepts can be mapped to IcePanel:
- Domains in DDD as Landscapes in IcePanel
- Subdomains in DDD as Domains in IcePanel
- Bounded context as Groups in IcePanel
Returning to our e-commerce example, the IcePanel Landscape can be treated as the domain (in DDD) representing the core problem being solved-“Online shopping.” Domains in IcePanel can be used to represent different sub-domains in DDD, such as “inventory management,” “order fulfillment,” “checkout,” “payment processing,” etc. Lastly, Groups can represent bounded context areas within each domain (subdomain in DDD).
Level 2 diagram with ‘Shipping’ Group for the bounded context
Another option is to use tags to represent these concepts. Create a tag group for the bounded context options and multi-select to assign tags to objects quickly.
Level 2 diagram with ‘Shipping’ tag for the bounded context
🏁 Final thoughts
The C4 model defines a simple standard to model software architecture with enough flexibility to represent different architectural patterns. If you’re new to the C4 model or are transitioning from other methodologies like UML, it requires a small shift in thinking to what you might have been used to. These changes are designed to help you model key patterns consistently across your team. If there are other architecture patterns you’d like help modelling, let us know!
