C# Project Configuration

When designing a project and laying out the architecture I start from two directions.
First I look at the project being designed and determine what the buisness problems
is that needs to be solved. I look at the people who will be using it and start with a
crude UI design. At this point I am ignoring the data and just looking at what the
users are asking for and who will be using it.
Once I have a basic understanding of what they are asking for I determine what the
core data is that they will be manipulating and begin a basic database layout for that
data. Then I start to ask questions to define the business rules that surround the
data.
By starting from both ends independantly I am able to lay out a project in a way that
melds the two ends together. I always try to keep the designs seperate for as long as
possible before melding them together, but keep in mind the requirements of each
as I move forward.
Once I have a good solid understanding of each end of the problem I begin to lay out
the structure of the project that will be created to solve the problem.
Once the basic layout of the project solution is created I look at the functionality of
the project and set up a base set of namespaces that are used depending on the
type of work being done. This may be things like Account, Shopping Cart, Surveys,
etc.
Here is the basic solution layout that I always start with. As the projects get better
defined I refine it to meet the specific needs of the project. Some areas may be
merged with others and I may add a few special ones as needed.
SolutionName
.ProjectNameDocuments
For large projects there are certain documents that need to be kept with
it. For this I actually create a seperate project or folder within the
solution to hold them.
.ProjectNameUnitTest
Unit testing always depends on the project some times it is just really
basic to catch edge cases and some times it is set up for full code
coverage. Recently have added graphical unit testing to the arsenal.
.ProjectNameInstaller
Some projects have specific installation requirements that need to be
handled at a project level.
.ProjectNameClassLibrary
If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
I am adding this because I just found a need for one in my current project.
This project holds the following types of scripts: SQL (Tables, procs, views),

SQL Data update scripts, VBScripts, etc.

.ProjectName
.DataRepository
Contains base data classes and database communication. Sometimes
also hold a directory that contains any SQL procs or other specific
code.
.DataClasses
Contains the base classes, structs, and enums that are used in the
project. These may be related to but not necessarily be connected to
the ones in the data repository.
.Services
Performs all CRUD actions with the Data, done in a way that the
repository can be changed out with no need to rewrite any higher
level code.
.Business
Performs any data calculations, business level data validation, does
most interaction with the Service layer.
.Helpers
I always create a code module that contains helper classes. These
may be extensions on system items, standard validation tools,
regular expressions or custom built items.
.UserInterface
The user interface is built to display and manipulate the data.
UI Forms always get organized by functional unit namespace with an
additional folder for shard forms and one for custom controls.