We all coders here, basically. What I’m going to ask you, is how you’re struct you solution/project to reflect even in rough way the structure of what you develop.
How you gonna describe dependency of one class from another in code, how you gonna structure your solution in a way that after a couple of years someone new to your project is able to understand (more or less) the code dependencies in your solution?
Give the first answer, just to give another hint what I’m really asking about:
We can use common tools/frameworks in our development: NHibernate, ASP.NET MVS, WPF… which will lead us to structure the code in several way, so someone who is familiar with that tool will understand just looking on the project of, let’s say VisualStudio, how your project is basiclally structured.
P.S: I’m aware of Diagram tools, Visio or whatever, my question is: do you ever think about this from coding prespective?
To add to @Joakim’s point in a comment above, a key way to do this really does center around abstraction. One thing I make an effort to do in all my .NET projects is to confine external dependencies to their own projects in Visual Studio. Those projects are injected with an IoC container (also abstracted with a service locator setup) to fulfill the abstracted interfaces.
So the central domain logic is just internal code. No dependencies. Basically, that project doesn’t reference anything, everything references it. It’s just the business logic (models, interfaces for dependencies such as data repositories, etc.).
Then an external dependency (which could be a database by means of a data access framework, an external service of some kind, or even just a 3rd party library such as the IoC container) would be used in its own project and implement the domain interfaces that it needs to implement. This keeps the dependencies clear and separated, so they can be easily identified and potentially replaced without ever touching the internal business logic.