domain-driven-design - libro - que es ddd

DDD y persistencia de implementación

Question

Me estoy mojando los pies con DDD (en .Net) por primera vez, ya que estoy rediseñando algunos componentes centrales 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 en sí mismos son persistentes e ignorantes, y deben diseñarse utilizando el "lenguaje ubicuo" y, ciertamente, no deben ser forzados a las restricciones del DAC del mes o incluso de la base de datos física.

¿Estoy en lo cierto al afirmar que las interfaces del repositorio viven en el ensamblaje del dominio, pero las implementaciones del 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 cierto al afirmar que las Interfaces de Repository viven dentro del ensamblaje del Dominio, pero las Implementaciones de Repository existen dentro de la capa de persistencia? La capa de persistencia contiene una referencia a la capa de dominio, nunca al revés?

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

• Capa de presentación (formularios de formularios, formularios web, asp.net MVC, WPF, php, qt, java, ios, android, etc.)
• Business Layer (a veces llamado gerentes o servicios, la lógica va aquí)
• Capa de acceso a recursos (manualmente u ORM)
• Recurso / Almacenamiento (RDBMS, NoSQL, etc.)

El supuesto aquí es que cuanto más alto eres, más volátil es la capa (más alto es la presentación y más bajo es el recurso / almacenamiento). Es por esto que no desea que la capa de acceso a recursos haga referencia a la capa de negocios, ¡es al revés! La capa de negocios hace referencia a la capa de acceso a recursos, usted llama ¡ABAJO no ARRIBA!

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

Answer 2

¿Estoy en lo cierto al afirmar que las Interfaces de Repository viven dentro del ensamblaje del Dominio, pero las Implementaciones de Repository existen 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)?

Podría ser una buena idea no pensar en términos de CRUD porque se centra demasiado en los datos y puede llevarlo a la trampa del repositorio genérico . Repository ayuda a administrar la mitad y el final de la vida útil de los objetos de dominio . Factories son a menudo responsables de comenzar. Tenga en cuenta que cuando el objeto se restaura desde la base de datos, se encuentra en la etapa de la mediana edad desde la perspectiva de DDD. Así es como puede verse 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 a este código directamente desde su aplicación. Tal vez valga la pena descargar y mirar la muestra DDD de Evan. El patrón de unidad de trabajo generalmente se emplea para tratar transacciones y abstraer el ORM de su elección.

Answer 3

Vea lo que Steve Bohlen tiene que decir sobre el tema. El código para la presentación se puede encontrar here .

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