DDD e implementación de persistencia

Question

Me estoy mojando los pies con DDD (en .Net) por primera vez, ya que estoy reorganizando algunos componentes principales de una aplicación empresarial heredada.

Algo que quiero aclarar es, ¿cómo implementamos la persistencia en una arquitectura DDD adecuada?

Me doy cuenta de que los dominios son persistentes ignorantes, y deben diseñarse utilizando el "lenguaje ubicuo" y ciertamente no forzados a las limitaciones del DAC del mes o incluso la base de datos física.

¿Es correcto que las interfaces de repositorio vivan dentro del conjunto de dominio, pero las implementaciones de repositorio existen dentro de la capa de persistencia? La capa de persistencia contiene una referencia a la capa de Dominio, nunca al revés?

¿Desde dónde se llaman mis métodos de repositorio reales (CRUD)?

Answer 1

Estoy en lo correcto que las interfaces de repositorio viven dentro del ensamblaje de dominio, pero existen las implementaciones del repositorio dentro de la capa de persistencia ? La capa de persistencia contiene una referencia a la capa de dominio , nunca al revés?

Sí, este es un muy buen enfoque.

¿Desde dónde se llaman mis métodos de repositorio reales (CRUD)?

Puede ser una buena idea no pensar en términos CRUD porque está demasiado centrada en los datos y puede llevarlo al Generic Repository Trap. Repository ayuda a administrar el medio y el final de la vida para domain objects. Factories son a menudo responsables de comenzar. Tenga en cuenta que cuando el objeto se restaura desde la base de datos, se encuentra en su etapa de mediana edad desde la perspectiva DDD. Así es como se ve el código:

// beginning 
Customer preferredCustomer = CustomerFactory.CreatePreferred(); 
customersRepository.Add(preferredCustomer); 

// middle life 
IList<Customer> valuedCustomers = customersRepository.FindPrefered(); 

// end life 
customersRepository.Archive(customer); 

Puede llamar este código directamente desde su aplicación. Tal vez vale la pena descargar y mirar Evan's DDD Sample. El patrón Unit of Work se emplea generalmente para tratar transacciones y abstraer su ORM de elección.

Answer 2

Echa un vistazo a Steve Bohlenhas to say sobre el tema. El código para la presentación se puede encontrar here.

Estuve en la presentación y encontré buena información sobre cómo modelar los repositorios.

Answer 3

Estoy en lo correcto que las interfaces de repositorio viven dentro del ensamblaje de dominio, pero existen las implementaciones del repositorio dentro de la capa de persistencia ? La capa de persistencia contiene una referencia a la capa de dominio , nunca al revés?

estoy de acuerdo aquí, digamos que un sistema se compone de las siguientes capas:

• capa de presentación (ganar formas, formularios web, asp.net MVC, WPF, php, qt, java,, ios, android, etc.)
• Capa de negocios (a veces llamados gestores o servicios, la lógica va aquí)
• acceso a los recursos de Capa (manual o ORM)
• Recursos/Almacenamiento (RDBMS, NoSQL, etc.)

El supuesto aquí es que cuanto más alto es, más volátil es la capa (la presentación es la más alta y la más baja es la de recurso/almacenamiento). Es por esto que no desea que la capa de acceso a los recursos haga referencia a la capa empresarial, ¡es al revés! La capa de negocios hace referencia a la capa de acceso a recursos, ¡usted llama DOWN no ​​UP!

En su lugar, pone las interfaces/contratos en su propio ensamblaje, no tienen ningún propósito en la capa de negocios en absoluto.