Al diseñar un proyecto y diseñar la arquitectura, comienzo desde dos direcciones. Primero observo el proyecto que se está diseñando y determine cuáles son los problemas de negocios que deben resolverse. Miro a la gente que lo usará y comienzo con un diseño de IU en bruto. En este punto, estoy ignorando los datos y solo miro lo que piden los usuarios y quién los usará.
Una vez que tengo una comprensión básica de lo que están pidiendo, determino cuáles son los datos centrales que estarán manipulando y comenzar un diseño básico de la base de datos para esos datos. Luego comienzo a hacer preguntas para definir las reglas de negocio que rodean los datos.
Partiendo de ambos extremos de forma independiente, puedo diseñar un proyecto de forma que se fusionen los dos extremos. Siempre trato de mantener los diseños separados por el mayor tiempo posible antes de fusionarlos, pero tenga en cuenta los requisitos de cada uno a medida que avanzo.
Una vez que tengo una buena comprensión sólida de cada extremo del problema, comienzo a diseñar la estructura del proyecto que se creará para resolver el problema.
Una vez que se crea el diseño básico de la solución del proyecto, observo la funcionalidad del proyecto y configuro un conjunto básico de espacios de nombres que se utilizan según el tipo de trabajo que se realice. Esto puede ser cosas como Cuenta, Carrito de compras, Encuestas, etc.
Aquí está el diseño de la solución básica con el que siempre comienzo. A medida que los proyectos se definen mejor, lo refino para satisfacer las necesidades específicas de cada proyecto. Algunas áreas pueden fusionarse con otras y puedo agregar algunas especiales según sea necesario.
SolutionName
.ProjectNameDocuments
For large projects there are certain documents that need to be kept with
it. For this I actually create a separate 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.