trato de mantener las cosas muy simple siempre que puedo, por lo general algo como esto funciona para mí:
Myapp.Domain - Todas las clases específicas de dominio comparten este espacio de nombres
Myapp.Data - capa fina que abstrae la base de datos del dominio.
Myapp.Application - Todos "código de soporte", de registro, de código compartido de servicios públicos, los consumidores de servicios, etc
Myapp.Web - La interfaz de usuario web
Así clases serán por ejemplo:
- Myapp.Domain.Sales.Order
- Myapp.Domain.Sales.Customer
- Myapp.Domain.Pricelist
- Myapp.Data.OrderManager
- Myapp.Data.CustomerManager
- Myapp.Application.Utilidades de
- Myapp.Application.CacheTools
Etc.
La idea que trato de tener en cuenta sobre la marcha es que el espacio de nombres "dominio" es lo que capta la lógica real de la aplicación. Entonces, qué hay allí es con lo que puedes hablar con los "expertos de dominio" (los tipos que usarán la aplicación). Si estoy codificando algo por algo que han mencionado, debe estar en el espacio de nombres de dominio, y cada vez que codigo algo que no han mencionado (como registro, errores de rastreo, etc.) NO debería estar en el espacio de nombres del dominio.
Debido a esto, también soy cauteloso al hacer jerarquías de objetos demasiado complicadas. Idealmente, un esquema algo simplificado del modelo de dominio debería ser intuitivamente comprensible para los no codificadores.
Para este fin, normalmente no comienzo pensando en los patrones con mucho detalle. Intento modelar el dominio de la manera más sencilla posible, siguiendo solo las pautas de diseño orientadas a objetos estándar. ¿Qué necesita ser un objeto? ¿Como están relacionados?
DDD en mi mente se trata de manejar software complejo, pero si su software no es en sí mismo muy complejo para empezar podría terminar fácilmente en una situación en la que la forma de hacer DDD agrega complejidad en lugar de eliminarla.
vez que haya un cierto nivel de complejidad en su modelo que comenzará a ver cómo ciertas cosas deben ser organizado, y entonces sabrán qué patrones de uso, que las clases son agregados etc.
en mi ejemplo , Myapp.Domain.Sales.Order sería una raíz agregada en el sentido de que, cuando se instancia, probablemente contenga otros objetos, como un objeto de cliente y una colección de líneas de orden, y usted solo accederá a las líneas de orden para ese particular orden a través del objeto de orden
Sin embargo, para mantener las cosas simples, no tendría un objeto "maestro" que solo contenga todo lo demás y no tenga otro propósito, por lo que la clase de orden tendrá valores y propiedades útiles en la aplicación.
Así que voy a hacer referencia a cosas como:
Myapp.Domain.Sales.Order.TotalCost
Myapp.Domain.Sales.Order.OrderDate
Myapp.Domain.Sales.Order.Customer .PreferredInvoiceMethod
Myapp.Domain.Sales.Order.Customer.Address.Zip
etc.
Tiene sentido ... Orden y de atención al cliente es que AggRoots ¿verdad? Entonces, cuando hace referencia a su objeto Order, tiene que hacerlo como: Myapp.Domain.Sales.Order.Order ?? –
Sí y no, amplié mi ejemplo un poco, ya que la sección de comentarios es demasiado corta. – Console
Las clases 'Manager' en el espacio de nombres' Data' me recuerdan al modelo anémico –