Guide to Software Architecture Documentation
workingsoftware.dev
Guide to Software Architecture Documentation
1–10 of 60 posts
Re: Guide to Software Architecture Documentation
#2Re: Guide to Software Architecture Documentation
#3Re: Guide to Software Architecture Documentation
#4[deleted]
Re: Guide to Software Architecture Documentation
#5Re: Guide to Software Architecture Documentation
#6I mostly do free-form diagramming, mostly of process level architecture and integrations.
I haven’t looked at class level diagrams in years, which maybe says something about the limits of OOP and composition over inheritance.
On the data side I do like to have a stripped down ER diagram. By stripped down I mean a focus on the key tables and relationships, not every little table and key out there.
The purpose is always to show how data flows, where bottlenecks may be, how scaling happens, and how other non functional requirements are satisfied. Try to keep them simple and to the point, and do try to maintain them (at a minimum, date them!).
Outside of something specialized like a sequence diagram I actually usually just use Keynote.
Re: Guide to Software Architecture Documentation
#7Haven't used arc42. Seems mostly a German thing. Has anyone outside German speaking countries experience with it?
Re: Guide to Software Architecture Documentation
#8Re: Guide to Software Architecture Documentation
#9Big fan of C4. It's so simple most devs can contribute once some groundwork (initial diagrams) are done. Benefit is that software architecture is owned by the team, not just the architect. Haven't used arc42. Seems mostly a German thing. Has anyone outside German speaking countries experience with it?
Re: Guide to Software Architecture Documentation
#10Big fan of C4. It's so simple most devs can contribute once some groundwork (initial diagrams) are done. Benefit is that software architecture is owned by the team, not just the architect. Haven't used arc42. Seems mostly a German thing. Has anyone outside German speaking countries experience with it?
Oof... a lot to unpack in this phrase.
You would be surprised to learn how much "devs" actually know.
They may even recalibrate your ego a little bit if you were open to receive feedback.
Those "devs" are the people that have to turn architectural documentation into reality, sometimes ignoring it completely.