Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
It’s incredibly difficult to describe a complex system, regardless if you are developing a monolith or (micro) services. Use cases, code organization/navigation, interactions between services, and deployment/infrastructure are just some of the aspects that comprise the architecture of an entire system.
Depending on your role as a stakeholder, your view of the system can be very different than another stakeholder.
This blog post is in a series. To catch up check out these other posts:
- Context is King: Finding Service Boundaries
- Language
- Autonomous Services
- Focus on Service Capabilities, not Entities
Context Matters
There are many different stakeholders related to a software system, which all have different perspectives. Project/Project Managers, Developers, System Engineers, End Users all view a system in completely different ways. They view the system based on their own context.
In order to describe a system, it would be useful to define all the different viewpoints and how the overall use cases of the system.
4+1 Architectural View Model
We all have seen many books and articles where one diagram attempts to capture the gist of the architecture of a system. But looking carefully at the set of boxes and arrows shown on these diagrams, it becomes clear that their authors have struggled hard to represent more on one blueprint than it can actually express. Are the boxes representing running programs? Or chunks of source code? Or physical computers? Or merely logical groupings of functionality? Are the arrows representing compilation dependencies? Or control flows? Or data flows? Usually it is a bit of everything.
The paper by Philippe Kruchten, Architectural Blueprints—The “4+1” View Model of Software Architecture, defines 4 concurrent views from the point of view of the various stakeholders.
I recommend reading the paper but for an incredibly simplified version of the views:
- Logical View: The functionality. The service.
- Process View: Communication between processes and/or services.
- Physical View: Deployment of your services.
- Development View: File/Folder Structure of your codebase. What you’re looking at in your IDE/Editor
The +1 comes in from the scenarios view which is what your end users actually care about. It’s the system functionality/capabilities. The scenarios view is what guides all the other views.
Service Boundaries
Where I think general guidance has fallen short when developing (micro)services is just because you’ve identified multiple logical views ( services), does not mean that each must have their own independent deployment (physical view) or git repo (development view).
To be clear, there are obvious benefits to having independent deployments, but there are many disadvantages as well. But it’s not a requirement.
As an example, in .NET, you could have a solution with various projects that represent different logical views. None of these projects reference each other, they are simply in the same solution. There may however be an ASP.NET Core project that hosts these projects as a single process.
Point being is that just because you have multiple services does not necessarily mean they need to be developed independently or deployed independently.
The four views are representations of the system depending on the context. They don’t need to map 1:1.
When not everything maps 1:1, that’s when it makes it a bit more challenging finding service boundaries. Focus on the scenarios.
Blog Series
More on all of these topics will be covered in greater length in other posts. If you have any questions or comments, please reach out to me in the comments section or on Twitter.