Algunas preguntas sobre la estructuración de espacios de nombres de diseño impulsado por dominio

Question

Tengo algunas preguntas generales sobre el diseño del marco.

Estoy creando una API para una aplicación de iPhone en C# .NET (framework 3.5), & SQL 2008 (usando LINQ). He seguido el patrón-Driven Design-dominio (en un libro) y tener la siguiente estructura de carpetas:

Core 
- DataAccess 
--Impl 
-Domain 
-Impl 

Core es mi base de la biblioteca API - mis DLL. DataAccess contiene las interfaces de acceso a datos DataAccess.Impl contiene los repositorios (LINQ a la base de datos) El dominio contiene la mayoría de mis tipos de datos y propiedades. Impl contiene mis servicios (es decir AccountService.cs, EmailService.cs)

Ahora, como un ejercicio, he añadido un servicio de Windows a este proyecto y estoy intentando llamar a la funcionalidad de los archivos DLL en este servicio. MI PREGUNTA ES, ¿qué capa debo exponer a otras aplicaciones y qué debe permanecer oculto?

• ¿Las clases de servicio de la carpeta Impl deben ser lo que los programadores ven?
• O los repositorios de DataAccess.Impl?
• O, ¿debería simplemente exponerlo todo para que lo vean los programadores? Como parece ahora, esto parece un poco confuso.

cuando empecé a leer sobre DDD estaba asumiendo que los repositorios serían oculta y se accede por las clases de servicio, pero estoy encontrando necesito llamar funcionalidad tanto en mi cliente. ¿He diseñado esto mal?

Mi otra pregunta tiene que ver con el nombre del espacio de nombres. Cuando el servicio de Windows llamadas funcionalidad de mi biblioteca central, tengo que hacer mi incluye como tal:

using Company.Product.ProductCore.Core.DataAccess.Impl 
using Company.Product.ProductCore.Core.Domain 
using Company.Product.ProductCore.Core.Impl 

Esto parece prolijo. En cuanto a las DLL de Microsoft, parecen mantener una convención de dos niveles: (System.Linq, System.Text, etc.). Tener Company.Product.ProductCore.Core.Impl parece desordenado y realmente no le dice al programador qué hace este espacio de nombres (pero es lo que sugería el ejemplo que leí). ¿Hay una mejor práctica aquí?

Sus sugerencias (y cualquier ejemplo) son muy apreciadas.

Gracias.

Answer 1

El dominio definitivamente no es lo que estás buscando, en mi opinión, tampoco lo es tu capa de acceso a los datos.

En mi humilde opinión, lo que debería exponerse aún no está allí, es decir, una clase estática, digamos, si consideramos el patrón de diseño Fachada, que expone las características y funcionalidades de los subsistemas de la biblioteca.

El patrón de diseño de fachadas explicó:

1. Façade Design-Pattern - (Gang of Four);
2. Facade pattern (Wikipedia).

Así que, al final, ¿qué se supone que debe hacer su código? Simplemente exponga lo que es necesario, que debe saber, ya que es el único que sabe sobre el sistema que está desarrollando.

En resumen, a menudo utilizo el patrón de Fachada para que pueda aislar mis clases, implementaciones y varios subsistemas relacionados bajo el capó de una fachada. Consideremos que somos un distribuidor de automóviles completamente nuevo. Esta fachada serán los grandes ventanales que le permiten ver los autos expuestos en la sala de exposiciones. Tienes que pensar en lo que esta fachada expone. ¿Expone solo automóviles?

En mi opinión, esta fachada expone automóviles, que usted podrá comprar, pedir dinero prestado para comprar, reparar el automóvil, comprar otros accesorios relacionados, etc. Los accesorios estarán entonces expuestos, pero solo lo que necesita Lo mismo con los otros artículos como el automóvil. Es decir, es posible que desee exponer una interfaz únicamente y mantener la implementación por sí mismo, para que a través de su fachada, cuando tenga que devolver ICar o IAccessory, tenga que crear una instancia a través de su clase de objeto de implementación, luego devolver el instancia de interfaz a través de su fachada. Dicho esto, el usuario no necesita saber qué está sucediendo bajo el capó, pero solo que si quiere un auto, tiene que encargarlo a través de su fachada. Al igual que no irás a comprar un Mazda 3 a Mercedes Benz. Trabajarás con la fachada correcta. Por otra parte, los diferentes concesionarios de automóviles solo pueden ser subsistemas, de ahí algunas fábricas. Luego le pide a la fachada un automóvil con esta y esas especificaciones, y la fachada debe saber qué instancia de ICar para volver a cambiar por lo que le está pidiendo que le proporcione.

Espero que esto ayude de todos modos! =)

Answer 2

Si no me equivoco, que están haciendo dos preguntas:

1. cómo estructurar una aplicación DDD?
2. ¿Qué pasa con los nombres largos de espacio de nombres?

Mi respuesta es bastante larga: me tomé la libertad de dividirla en dos guiones.

Esta es una respuesta a la segunda pregunta: ¿

2. ¿Qué pasa con esos nombres de espacio de nombres largos

No creo que los nombres de espacio de nombres largos son necesariamente desordenado. mi humilde opinión, lo que se ve desordenado en sus nombres son:

• la repetición de las palabras "producto" y "Core"
• El uso del término general "Impl"

Una primera mejora podría BE:

// The Domain objects go here; 
MyCompany.MyProduct.Core.Domain; 
// DataAccess interfaces go here: 
MyCompany.MyProduct.Core.DataAccess; 
// a Linq implementation of the DataAcces interfaces go here: 
MyCompany.MyProduct.Core.DataAccess.LinqImpl; 
// The Core service go here: 
MyCompany.MyProduct.Core.Services; 
// Some general purpose infrastructure goes here (e.g. emailing code) 
Mycompany.MyProduct.Infra; 

por otra parte, me parece que el uso de un nombre de producto comercial (como MyProduct) en la estructura del código es malo (¿y si la comercialización elige un nombre diferente?); Me gusta usar el nombre de subsistemas lógicos en su lugar. Asumamos el sistema de alquiler de su auto. Entonces CarRental se considerará la funcionalidad principal de esta aplicación. A continuación, me gustaría usar la siguiente estructura de espacio de nombres (Serra es el nombre de mi empresa):

// For classes Customer, Account, Car 
Serra.CarRental.Domain;  
// I use Dao as a general abbreviation for "Data Access Objects" 
// Dao interfaces go here: 
Serra.CarRental.Dao;  
// Linq implementation for Dao interfaces 
Serra.CarRental.Dao.Linq; 
// For Services specific to the car rental domain: 
// AccountService and RentalService and CarAvailabilityService 
Serra.CarRental.Services; 
// For UI objects (not relevant in you situation?) 
Serra.CarRental.UI; 
// general service code; ignorant of the CarRental domain (e.g. an EmailService) 
Serra.Infra.Service;  

Answer 3

Dudo que los usuarios de su aplicación verán esto. Lo primero que necesitas es la funcionalidad. Esto es lo que venderás al final.

También necesita hacer los gastos de mantenimiento lo más bajo posible. Y aquí viene cómo está organizado tu código. Segundo: minimizar los gastos de mantenimiento.

Así que decidir cómo organizar su solución debe responder a algunas preguntas:

1. cómo la estructura recogido me ayudará para hacer un mantenimiento y la adición de nuevas características ?
2. ¿Cómo ayudará a los nuevos desarrolladores a comenzar la codificación dentro de mi solución ?
3. ¿Es todo lo que nombres de ensamblado/carpeta/clase son reconocibles y descriptivos?
4. Preguntas que olvidé.

Estos son sus objetivos. Pero no las reglas que estás buscando. Puede elegir cualquier nombre si el nuevo desarrollador lo entiende.

Probablemente (como una heurística y si utiliza algunas herramientas de refactorización como Resharper o Refactor! Pro) puede comenzar con el ensamblaje único y el espacio de nombre único. Durante el desarrollo, verá cómo puede cambiar la estructura de su proyecto para satisfacer mejor sus necesidades. Luego refactorízala.

Ve a ver este talk a las 38: 18-39: 45 (~ 1.5 minuto). Hay buenas prácticas sobre cómo responder algunas preguntas.