In the post I would like to discuss importance of the solution (project) structure nowadays. So, is it really so important to create and maintain a well structured solution when you have such a powerful IDE like VS.NET and a
plugin installed. ReSharper for sure improves development work and minimizes development effort. I‘ve seen number of times people saying that project structure is not important because such tool as ReSharper allows you to easily: navigate thru solution, project, classes ect… refactor code with no pain without knowing where the classes are used, find any class, .dll, usages, inheritor, base… within entire solution, and many, many other cool things… even it will purpose to add a .dll reference if a class is in another project.
OK... VS.NET + ReSharper are powerful... but that is enough?
Let’s see… for small business projects in mostly cases importance of a good
solution\project structure is not high, because there will not be a very big
gain from that structure, same is for design decisions, tool set etc...
For large projects “ReSharper shortcuts” are not enough. Why?
Because it can help but it can’t do for you:
- correctly define number of libraries and granularity
- correctly define references(dependencies) between libraries
- devise classes in namespaces - create intuitive folder structure
- say where fits new class\interface\enum\etc. and how to name it
- create project structure conventions (e.g. naming convention)
- define a big picture
enumerated above statements are very important for a larger projects. A
correctly set project structure can say a story about the project: where it is
now and what future of the project is. By future of the project I mean that is
more predictable. Change impact and major changes will more transparent. Self
explanatory project structure is very important, not only for beginners in a
project but also for persons that works for a module\project\layer separately.
It will allow easily decide changes, reuse, and share common language within
team members. Most of the development time we “read “ code\module\layer, so in
some stage of a project “write” time begins to depends on “read” time, good
project structure allows to concentrate only on one thing at a time, decrease
“read” time. Code responsibilities are more visible and more isolated(less
dependent), increasing reusability.
If a project structure doesn’t say anything about the project or you don’t know
where to fit new peace of code then it’s a sign that is something wrong, in this
case project should be refactored. Project structure is like a piece of code
that should be refactored when it doesn’t meet his needs, Yes, it is not so
easy… but is easier to spend hours\days on things that should take considerably
For small project, project structure it’s not so important, main purpose of
small projects is not maintenance but is to finish it quickly and often dirty.
As opposite, for large projects any decision is more important and its
consequences are more visible, these decisions are reflected in maintenance
time, nowadays maintenance is a key for large long term projects. So, project
structure is high-level description of a project that has more value for large
projects, because it can reduce maintenance costs.
I will not discuss “How to define a project structure” because it is not purpose
of the post but I will point to set of principles that can help you to organize
a correct project structure, so there a few general principles which are
1) The Reuse/Release Equivalence Principle (REP) - THE GRANULE OF REUSE
IS THE GRANULE OF RELEASE. ONLY COMPONENTS THAT ARE RELEASED THROUGH A TRACKING
SYSTEM CAN BE FFECTIVELY REUSED. THIS GRANULE IS THE PACKAGE.
2) The Common Reuse Principle (CRP) - THE CLASSES IN A PACKAGE ARE REUSED
TOGETHER. IF YOU REUSE ONE OF THE CLASSES IN A PACKAGE, YOU REUSE THEM ALL.
3) The Common Closure Principle (CCP) - THE CLASSES IN A PACKAGE SHOULD
BE CLOSED TOGETHER AGAINST THE SAME KINDS OF CHANGES. A CHANGE THAT AFFECTS A
PACKAGE AFFECTS ALL THE CLASSES IN THAT PACKAGE.
4) The Acyclic Dependencies Principle (ADP) - THE DEPENDENCY STRUCTURE
BETWEEN PACKAGES MUST BE A DIRECTED ACYCLIC GRAPH (DAG). THAT IS, THERE MUST BE
NO CYCLES IN THE DEPENDENCY STRUCTURE.
5) The Stable Dependencies Principle (SDP) - THE DEPENDENCIES BETWEEN
PACKAGES IN A DESIGN SHOULD BE IN THE DIRECTION OF THE STABILITY OF THE
PACKAGES. A PACKAGE SHOULD ONLY DEPEND UPON PACKAGES THAT ARE MORE STABLE THAT
6) The Stable Abstractions Principle (SAP) - PACKAGES THAT ARE MAXIMALLY
STABLE SHOULD BE MAXIMALLY ABSTRACT. INSTABLE PACKAGES SHOULD BE CONCRETE. THE
ABSTRACTION OF A PACKAGE SHOULD BE IN PROPORTION TO ITS STABILITY.
All the principles can be found
However, SOLID principles also could be applied for a solution\project
structure. Last two principles are described in
Organizing a project structure we define its: modularity, dependencies, common
language, conventions, cohesion level, first face of the application, etc.. how
a tool can replace it? It can only help…