DDD, NHibernate, y estructura/nombre de proyecto

Question

¿Cuál es la estructura de proyecto adecuada para una solución de WebForms que utiliza NHibernate y trata de incorporar algunos conceptos de DDD?

Suponiendo que el espacio de nombres raíz y nombre de la solución de la muestra es

• Sample.Domain - contiene mis objetos de dominio y mis archivos de asignación
• Sample.Repositories - contiene mis repositorios y archivo de configuración de conexión nhibernate
• Muestra .Negocios: contiene mi lógica comercial
• Sample.Web - el proyecto real de WebForms - todo Presentación

¿Qué estoy olvidando? ¿Hay una forma más estándar de nombrar estos?
¿Alguna buena publicación de blog sobre el tema?

Answer 1

Algunas partes que faltan parecen ser una ubicación central para los servicios necesarios en toda la solución y proyectos de prueba. Por lo general tienen algo como esto:

• Sample.Core - servicios y el código que necesitan ser utilizado a través de la aplicación
• Sample.Data - clases de dominio y las interfaces de repositorio
• Sample.Data.NHibernate - mapeo archivos de configuración, fluidez, etc., y las implementaciones del repositorio de datos, básicamente cualquier cosa capa de asignación específica
• Sample.Services - implementaciones de servicios e interfaces
• Sample.Web - aplicación web

que tienen un árbol de juego de los proyectos de prueba:

• Ensayos \ Sample.Core.Tests
• Ensayos \ Sample.Data.NHibernate.Tests
• etc ...

Por supuesto, el árbol se volverá más complejo dependiendo del proyecto. En cuanto a las discusiones, consulte el Onion Architecture. También puede consultar los proyectos de muestra en Domain-Driven Design y ver qué puede tomar de ellos.

Answer 2

he encontrado cada uno tiene sus propias preferencias para la denominación, prefiero:

• Sample.Domain - objetos de dominio, archivos de asignación
• Sample.Services - la lógica de negocio y servicios (y repositorios, aunque podría ver separarlos)
• Sample.Web - Web Stuff.
• Sample.Migrations - Migraciones de datos.

Ben Scheirman también publicó recientemente acerca de esto: Exporting Visual Studio Solutions with Solution Factory.

Utiliza una estructura diferente, pero también incluye una gran manera de estandarizar su plantilla.

Answer 3

Lo mantengo simple y delgado para segregar por espacio de nombres en lugar de por proyecto, especialmente al principio. Normalmente comienzo con tres proyectos en la solución:

• Ejemplo - contiene espacios de nombre Sample.Model, Sample.Model.Mappings, y Sample.Services.
• Sample.Tests - contiene pruebas unitarias está estructurado de la misma manera que Sample.
• Sample.Web - UI

Answer 4

Se puede ver cómo se hace en s#arp architecture. Es un marco arquitectónico muy sólido