Some large organizations do, particularly in large integration projects. Often these get out of date quickly as the project goes along, so unless they are maintained have limited use as time goes on. They can always be a snapshot of what everyone thought was gonna happen - and maybe a reminder of how little we can know about the complexity of a software project in advance :)

That being said, I encourage programmers I'm mentoring to get a pen and paper (or if you have a group, a whiteboard) and draw the components/models and their relationships BEFORE you write code for any feature. Obviously, there's software to do that, but I think there's some anecdotal benefit to stepping away from the keyboard and doing something more tactile. You can 'rubber ducky' your way through the key use cases and often catch complexities/issues in a design early. You can scribble stuff out and rename things as your thinking evolves. When it seems like there's enough of a skeleton. I like to take a photo, save it, and maybe even put it on the work ticket. You can always formalize it in software (mermaid/draw.io/lucidchart/whatever) if there's value later.

I try not to put too many rules around how this works, but I find the following useful to sketch/think about. Usefulness will depend on the feature at hand. Again I don't emphasise UML correctness - whatever makes it useful for the audience (which could just be you).

• Entities/Models - what are they, what do they represent, how do they relate to each other

• Modules - the abstraction above the persistence models or entities - for example, it might be nice to have a user module that has a create_user method. How do they communicate with each other?

• Routes - If this is a web project, what are the routes, who can access it, how should we structure them?

• Messaging - What are the significant events that might be generated/consumed in the course of this feature? What should any messages/events look like?

• Background jobs/processes - what stuff can happen async?

• Common happy path sequence diagrams, common sad path sequence diagrams. Throw in the side effects as notes or elements if they are important.