domain driven design - quickly - DDD: ¿Qué tipo de comportamiento debo poner en una entidad de dominio?
principios ddd (4)
Mi equipo hace un gran esfuerzo por mantener el Diseño Dirigido por Dominio como una estrategia arquitectónica. Pero, la mayoría de las veces, nuestras entidades de dominio son bastante enímicas. Nos gustaría poner más comportamiento de negocios / dominio en nuestras entidades de dominio.
Por ejemplo, Active Record coloca el acceso a los datos en la entidad. No queremos eso porque utilizamos felizmente el patrón de repositorio para el acceso a los datos.
Además, diseñamos nuestro software para que sea SOLID (los cinco principios de diseño de software que Tío Bob creó). Por lo tanto, es importante para nosotros que prestemos atención a la responsabilidad única, la apertura y el cierre, liskov, la segregación de interfaces y la inversión de dependencia al diseñar nuestras entidades.
Entonces, ¿qué tipo de comportamiento debemos incluir? ¿De qué tipos debemos mantenernos alejados?
Algún comportamiento que trato de poner en mi dominio, entidades u objetos de valor.
Validación ante persistencia. validación antes de la transición a un nuevo estado. Por ejemplo, la entidad raíz agregada de orden puede validar su estado interno y sus hijos agregados antes de pasar al estado Enviado. Minimice las propiedades de los conjuntos de valores y utilice los objetos de valor todo lo que pueda. Primero hace que el modelo sea más rico con el comportamiento. Las entidades se vuelven más descriptivas. en segundo lugar, más raramente pone a su entidad en un estado no válido si debe usar métodos de objetos de valor como el método ApplyAdress en una entidad personal que toma un objeto de Valor de dirección como en el parámetro.
¿Qué más ... Info Inteligencia. use su entidad y sus objetos de valor para controlar y restringir la información agregada. Al igual que la identidad personal puede ser un objeto de valor que maneja la uniqeuness de una persona. Incapsula ssn, ssn algoritm, maneja suma de comprobación de género en ssn etc.
El comportamiento que se encuentra en sus entidades debe reflejar el modelo de negocio. Lo que se puede hacer para o por esa entidad es que el mundo de los negocios debe ser una solución que se pueda hacer para o por la clase de entidad. Por ejemplo:
En un sistema de compras en línea, puede agregar un producto a su carrito. Así que la clase de carrito debería verse así:
public class Cart
{
//...
public void AddProduct(Product product)
{
...code to add product to cart.
}
}
Se podría argumentar que los metidos deben reflejar los casos de uso.
Ha pasado casi un año desde que hice esta pregunta y mi equipo y yo hemos aprendido mucho desde entonces. Así es como respondería esta pregunta hoy:
El dominio debe representar (en código) lo que el negocio es o hace (en la vida real). Las entidades de dominio, entonces, son los artefactos o actores que se encuentran en ese negocio de la vida real. ¿Qué tipo de comportamiento tienen esos artefactos y actores reales? Todo ello. A su vez, ¿qué tipo de comportamiento DEBERÍAN tener las entidades de dominio sobre ellos? Todo ello.
Por ejemplo, en la vida real, un gerente puede contratar a un nuevo empleado. La representación del dominio de eso debe incluir entidades como "administrador" y "nuevo empleado". El manager es el actor, aquí.
//newEmployee comes from somewhere else... possibly the UI
//someManagerId comes from the logged in user
var manager = _repository.Get<Manager>(someManagerId);
manager.Hire(newEmployee);
Entonces, la entidad gestora modela / refleja el comportamiento de los negocios de la vida real, aquí. La alternativa es omitir a la entidad gerente como actor, y empujarlo a la esquina para que un "servicio de dominio" de trabajo pesado pueda hacer todo el trabajo ... así:
//newEmployeeService comes from somewhere else... possibly injected using IOC
newEmployeeService.Create(newEmployee, someManagerId);
En un dominio anémico, usaría un servicio de dominio como este para crear o contratar a un empleado. Funciona, pero no es expresivo y el comportamiento no es tan visible. ¿Quien hace que? ¿Por qué se requiere que el gerente cree un nuevo empleado?
Creo que cuando hice la pregunta originalmente, quería comenzar a incluir más comportamientos en mis entidades, pero realmente no sabía cómo inyectar servicios en mis entidades (por ejemplo, con inyección de constructor). Desde entonces, hemos aprendido algunos trucos nuevos y las entidades de nuestro equipo son muy expresivas. Aquí está, en pocas palabras, lo que estamos haciendo:
- Intentamos, cuando es posible, usar entidades de actor para expresar la persona o cosa que está realizando la acción.
- Los actores tienen métodos que expresan las acciones que pueden realizar.
- Cuando se necesita un servicio, se inyecta como un argumento en el método donde se usa.
- BlingBag eventos de dominio utilizando BlingBag en cada método en cada entidad de dominio para proporcionar extensibilidad y dar a las entidades la capacidad de auto persistir.
Si tiene que preguntar qué comportamiento debe poner en la entidad de dominio, entonces probablemente no necesite DDD. Estoy tratando de ser de ayuda aquí, porque he tenido mucho dolor al colocar la DDD en un lugar al que no pertenecía.
DDD o incluso el modelo de dominio son patrones que se pueden seguir una vez que se descubre que la complejidad del dominio es demasiado alta para que funcione cualquier otro patrón. Así que solo CRUD no es adecuado para DDD. Según tengo entendido, DDD se ajusta cuando tiene un contexto acotado que contiene reglas de negocio complejas que deben ejecutarse antes del estado de transición para la raíz agregada. Por eso no incluiría la validación en la definición de complejo.
El tipo de comportamiento que desea establecer en sus entidades está íntimamente relacionado con el problema comercial que está tratando de resolver. La preocupación acerca de la persistencia (repositorio, etc.) debe aparecer después (de hecho, la persistencia puede estar en un flujo de trabajo o almacén de eventos).
Espero que esto ayude.