I dunno, I kind of subscribe to software architecture being like, a set of design decisions that guide the implementation. That's what (in my experience) most software architects do; lay down guidance and structure for the software engineers.
> The C4 model was created as a way to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectively documenting an existing codebase.
> It's a way to create maps of your code, at various levels of detail, in the same way you would use something like Google Maps to zoom in and out of an area you are interested in.
This seems different.
I have no idea why you would refer to the a code diagram as your software architecture. That's literally the code level. How is that architectural?
It's like saying the circuit diagram in the plug should go on the house blueprint. "You should use automated tools for this" ... so, it's for documenting existing code bases at the per-function level?
How is that useful for architecting / designing / planning software?
That sounds like software structure to me, not software architecture.
Sure, a map of existing software that explains how it's structured sounds cool... but I dunno. Like, if you're talking about design patterns, you're not gonna give someone a function-by-function map of how to implement a singleton. They're not stupid. You'd tell them you think it should have a singleton (or repository, or whatever).
Software design is totally a thing, and this seems entirely reasonable for designing software.
...but software design and implementation and software architecture are not the same thing and they're not done by the same people, in my experience.
This feels more like... systems design, which a software architect would contribute advice to in the way that the systems were designed so they aligned with good software architecture principals.
> I dunno, I kind of subscribe to software architecture being like, a set of design decisions that guide the implementation.
I think this is the one mandatory part of software architecture which is giving developers information to help them make their own design decisions without constantly deferring to the authority.
But the exact place where architecture ends and development starts varies a lot.
I like to think that architecture itself decides what is important from the architecture standpoint. If architecture decides a certain low level application detail is important, then it becomes an architecture detail.
In fact, in most organisation architecture controls at the very least some top level design like components, communication patterns, APIs and technology in use.
In some organisation architecture goes as far as individual classes. Not all classes, but maybe classes modelling the domain of the problem especially, if that model is used as a language for multiple project or even implemented as a shared artifact.
I think C4 is suitable for those organisations where architecture is concerned with more low level structure than just listing applications and their integration interfaces.
* Have a high level blueprint of the house for typical humans.
* Have a detailed blueprint of the house for contractors.
* Have a circuit diagram for the utility systems like electricity
* (Optional) Have a detailed specification for every plug and fixture etc.
Basically, have a diagram for every level that will be notably unique or useful to have for the system. If you need a code level diagram, either you're doing some complicated custom work or most likely over specifying the design that can be left as an implementation detail.
Interesting, as I kinda share also that there are lines to be drawn between software architecture, design and implementation (all three).
Much like in the real world building of real-estate for example, I see there are different roles between the architect vs the engineers vs. the foremen.
What do you draw the line? What concerns/areas are to be covered in each of these [arch vs design vs implem]?
> The C4 model was created as a way to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectively documenting an existing codebase.
> It's a way to create maps of your code, at various levels of detail, in the same way you would use something like Google Maps to zoom in and out of an area you are interested in.
This seems different.
I have no idea why you would refer to the a code diagram as your software architecture. That's literally the code level. How is that architectural?
It's like saying the circuit diagram in the plug should go on the house blueprint. "You should use automated tools for this" ... so, it's for documenting existing code bases at the per-function level?
How is that useful for architecting / designing / planning software?
That sounds like software structure to me, not software architecture.
Sure, a map of existing software that explains how it's structured sounds cool... but I dunno. Like, if you're talking about design patterns, you're not gonna give someone a function-by-function map of how to implement a singleton. They're not stupid. You'd tell them you think it should have a singleton (or repository, or whatever).
Software design is totally a thing, and this seems entirely reasonable for designing software.
...but software design and implementation and software architecture are not the same thing and they're not done by the same people, in my experience.
This feels more like... systems design, which a software architect would contribute advice to in the way that the systems were designed so they aligned with good software architecture principals.
Maybe I'm just being pedantic. /shrug