How are large C# solutions organized so that programmers can see the?
I develop software in C# for a manufacturer of scientific instruments / lab equipment. The software I develop is related to control and operation of the instruments (R&D) we sell as products, not the operations of the business. High level managers dont typically look at or understand code. They look at specifications and the more technically minded of them may look at architectural diagrams. Many of our high level managers are Phd chemists or other science-based Phds a few may be engineers, but usually not software engineers or engineers closely associated with software development. Generally, where I work, the project lead will organize the project. New coders are onboarded: introduced to its varied components, focusing on where they are going to be used. I should note that we do not usually do CRUD applications. For CRUD applications there are patterns like MVVM and MVC where there are typically best practices available and widely understood. You can read about them in any number of books on the subject. For the UI components of our software, we typically use WPF and MVVM. Views go in a folder called Views. View Models go into a folder called ViewModel. Then under each there are a parallel hierarchy of subfolders that organize the components logically. The model is tricker for us. The model is the back-end that connects to our analytical instruments, tracks instrument status, sends commands from the ui to the instrument, sends updates to the ui applications about what the instrument is currently doing as well as results at the end of a run. For CRUD applications the model may be a SQL database or something similar. For simpler applications the distinction between model and view model tends to blur a bit in my experience. The ui accesses the model typically through a proxy object that allows dual-channel interprocess communication with the backend. This is almost always a local (same computer) connection on a Windows workstation located in a laboratory connected to the instruments. If there are accepted best practices for the type of development you do, pick one and follow it. Whatever you do the key is to achieve separation of concerns. Keep ui/display logic code separate from the code that actually does the work you are doing. Depending on what approach you take to UI development, further separate the display code according to the principles of MVVM or MVC or whatever you come up with.