¿Cómo factoriza su dominio (espacios de nombres) en el diseño impulsado por dominio?
-
03-07-2019 - |
Pregunta
¿Cómo factoriza su dominio (espacios de nombres) en el diseño controlado por dominio?
Me he pasado al siguiente concepto:
Project.Entity
Project.Entity.Abstracts
Project.Entity.Entities
Project.Entity.Extensions
Project.Entity.Immutables
Project.Entity.Interfaces
Project.Entity.Repositories
Por ejemplo, tengo una entidad en un CMS llamada "Contenido". Entonces, crearía un proyecto llamado Project.Content, y factorizaría las clases para que se vean así:
interface IContent
class Content : IContent
interface IContentRepository
class ContentRepository : IContentRepository
Este " Contenido " El modelo de entidad tendría su propio espacio de nombres.
Pero, creo que no escala bien en un gran entorno empresarial con más de una docena de proyectos (prueba 18) de "Entidad" modelos. Termino con una solución con más de una docena de proyectos, algunos de los cuales solo tienen 2 o 3 clases (es decir, UrlRewriter). Además, me encuentro haciendo referencia a otros proyectos solo por sus interfaces. Siento que esto está contaminando mi dominio; Si bien no son referencias concretas, a veces es difícil evitar referencias circulares.
Entonces, vuelvo a la "Capa" concepto a veces ...
Quiero saber cómo otros expertos DDD están factorizando aplicaciones de tamaño empresarial. Por favor, siéntase libre de recomendar libros y artículos.
¡Y gracias de antemano!
Solución
Creo que lo que hago es agregarle algo que identifique el contexto acotado.
Ps. Para asegurarse de que está claro por qué, verifique ambos enlaces en el contexto acotado: http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html , http://devlicio.us/blogs/casey/ archive / 2009/02/11 / ddd-bounded-contextts.aspx
Otros consejos
Yo uso seguir las directrices de .NET . Los encuentro muy intuitivos y le permiten configurar espacios de nombres de modo que no necesite importar nada que no necesite.
Nunca impondría una convención de nomenclatura estricta para el nivel de característica. El diseño de cada proyecto diferente debería guiarlo.
De manera similar, descubrí que tener una gran cantidad de proyectos se vuelve difícil de manejar. Prefiero el
Project.Domain
Project.DataAccess
Project.Presentation (presenters and such)
Project.Gui (in case of a winforms app)
configuración.
En cierto modo, simplificar las cosas ayuda mucho cuando las cosas van mal.
La pregunta es ¿qué obtienes cuando creas otro proyecto? (es muy fácil hacerlo, casi demasiado fácil)
¿Alguna vez querrás usar ese proyecto de forma independiente o no? Puede terminar con los .dlls resultantes tan acoplados que ni siquiera puede implementarlos sin tener exactamente las mismas versiones, etc. en ese caso, hay pocas razones para dividirlo y saturar su IDE)
Siempre puedes mover las cosas a un nuevo proyecto más adelante si surge la necesidad, es algo doloroso, pero para ese momento tendrás una buena razón para hacerlo, aparte de la sensación de que es así.