domain-driven-design - significado - domain driven design pdf

Evitar el patrón de unidad de trabajo en el diseño impulsado por dominio

Question

He leído esto y me hace pensar dos veces ...:

"Evite el patrón de unidad de trabajo. Las raíces agregadas deben definir los límites de la transacción".

¿Por qué alguien debería evitar el patrón UOW que aplica el diseño controlado por dominio?

Answer 1

Básicamente, según M. Fowler , la UoW es "solo" una herramienta de persistencia inteligente (por muy compleja que sea esta tarea). De modo que, en mi humilde opinión, no existe una incompatibilidad intrínseca con el enfoque DDD, que proporciona directrices más sobre el "espíritu" de su modelado de dominación que sobre las herramientas técnicas.

Sin contexto, es difícil decir qué pensaba el autor de la cita; pero quizás escribió esto porque al usar UoW, a menudo es difícil permitir que sus entidades administren su propio ciclo de vida (y el de otros), generalmente con persistencia y comportamiento transaccional.

De hecho, es posible utilizar el patrón UoW en aplicaciones de estilo DDD con AOP . Con este tipo de herramientas, es posible mantener el espíritu de DDD, con modelo (s) de dominio con capacidad empresarial centrado en la entidad, al tiempo que se aprovechan mecanismos complejos pero ortogonales empresariales para lograr una persistencia transaccional adecuada.

Por lo general, en el mundo Java, puede usar en su aplicación DDD:

• Hibernate / JPA como UoW : proporciona "persistencia inteligente" de las entidades modelo de dominio (que también pueden ser JPA @Entity''s )
• Spring AOP + AspectJ : proporciona DI en las entidades.
• Spring TX + AspectJ : habilita métodos transaccionales en sus entidades

Éstos dan a las entidades listas para DDD (y fuertemente -nnotadas;]).

Answer 2

(Antes de mi publicación, recomiendo leer este capítulo del libro "Implementing Domain-Driven Design" de V. Vernon. Puede ayudar a acercarse a los agregados y contener una respuesta larga en su pregunta).

En un sistema adecuadamente diseñado, un comando cambia un agregado a la vez, cada agregado tiene límites que están definidos por invariantes en la raíz agregada. Por lo tanto, cuando realiza cambios en el agregado, se comprueban las invariantes y los cambios se aplican (o no) en una transacción. Es la consistencia de la transacción . ¿Necesitas usar la Unidad de Trabajo aquí? No lo pienses

Pero muy a menudo estamos en una situación en la que más de un agregado debe cambiarse al mismo tiempo. Las transacciones se vuelven más grandes, tocan más de una parte de un sistema y hablamos de consistencia eventual . UoW es un buen ayudante en este caso.

Como se ha mencionado sin contexto, es difícil adivinar qué pensaba el autor, pero supongo que habló sobre el caso de la consistencia de la transacción. En el sistema distribuido, necesitará usar algo como UoW para proporcionar una eventual consistencia a un sistema.