Question to all those who have worked with software architecture: What is your approach when implementing architecture and design into actual software?

I find it very hard to translate UML diagrams and architectural requirements into working code and I feel like there is quite a big "gap" between the two. How to you breach that gap and manage to maintain a clean and comprehensive architecture in your project folders?

I usually design top-down and implement bottom-up. Also integration testing works bottom-up. I have a rough idea what layers I need and what should go in which layer.

Then things grow and I realise I get too confused when looking for something, so I need to split things up. Either vertically by introducing a new layer, that's when I see too many things of different abstraction levels in one layer. Or horizontally, that's when there are too many things of the same abstraction level in the same place.

@Fast-Nop that sounds great, I'll keep that approach in mind when structuring my code :)

Specific question to you as I mostly work with layered architectures:
Do you name your subfolders according to its corresponding layer or do you think that it is better to give more insightful folder names according to its features?

@frickerg whether I even have folders or can get away with file names alone depends on the size. I usually try to give as much structure as needed, but as little as possible.

Something like maybe 50 files is fine with me, and then I'll first move the header files into an include directory of their own which cuts the number of files already roughly in half.

I've seen several nested folders depth which contained like one or two files in the leaves, and I find that confusing. But I guess Java devs are somewhat hardened with this phenomenon, especially enterprise SW devs.

@Fast-Nop I would find 50 files very overwhelming when I just want to find the entry point of the program. I do get the point of overstructuring when it's not necessary.

@frickerg I started with package-by-layer but moved to package-by-feature if that's what your'e asking him. This means every related file is in the same folder/package and I don't have to go finding files.

@Ederbit often, main() will be in main.c, but even if not, it's just using a file search for "main(" in Notepad++, so that's no biggy.

@Fast-Nop Thats true but if I want to be able to understand a component or feature it's nice to have it contained in one single folder.

@Ederbit yes I am a bit conflicted about whether package-by-layer or package-by-feature is better. I'm currently tring a hybrid of both, client and server in the root, interfaces in a middleware folder... From there I made feature-specific subfolders which are mostly separated by their corresponding layers.

I have never seen UML diagrams used in professional settings. That's kind of telling.

@frickerg I'd argue package-by-feature is better.

Code concerning a feature is more tightly coupled than code that happens to be on the same layer. That should be reflected in the package structure.

Also there's an interesting saying that looking at projects that package by layer tells you a lot about their technical architecture, but almost nothing about what they actually do. I think most of the time that's the more important information.

@frickerg Packaby-feature also adhere to the common reuse principle, one of the component principles described by bob martin in his book clean architecture.

Classes that are used together, should change together. I.e if I change the model class, i most likely have to change the Controller/Repository of this class as well. Meaning i put all of them inside one package. If you have a lot of classes inside the package, then it might make sense make a layer package inside the feature package.

@Root I am in academia until next year so it is a necessary evil for now 😂