propiedades de ID en objetos de dominio en DDD

7

En mi dominio tengo un objeto Account .

por ejemplo

class Account
{
    public string Number;
    public string SortCode;
}

Dentro del contexto de DDD, ¿debería este objeto de cuenta tener una propiedad ID ? El ID sería una clave principal, básicamente un artefacto de base de datos.

    
pregunta BanksySan 08.04.2014 - 15:21

3 respuestas

8

Depende. Si su clase Account se asignará a una base de datos relacional, entonces no es solo una buena idea, sino también una práctica comprobada, usar ID técnicos para cada tabla como PK (y FK, haciendo referencia a esos PK). Según mi experiencia, separar el PK técnico de todas las tablas de las "claves de dominio" (como el "número de cuenta bancaria") funciona muy bien y le ayuda a evitar todo tipo de problemas técnicos. Normalmente nombro esos PK no solo ID , sino <class-Name>Id , por lo que en su caso AccountID .

Si su clase anterior solo se usará como entrada para un generador de código que generará el código "real" de su lenguaje de implementación, así como sus declaraciones CREATE TABLE , algún código CRUD, etc., probablemente no lo haga. Necesito agregar el atributo ID en el código de clase directamente. Si va a utilizar un ORM, depende del ORM si puede agregar atributos de ID como PK automáticamente, o si espera que agregue esos ID manualmente.

En un contexto de DDD, es probable que sea útil ocultar esos detalles técnicos cuando discuta el modelo con sus expertos en dominios, pero muéstrelos cuando cambie su punto de vista a la implementación del modelo. Si su conjunto de herramientas le permite mostrar el modelo en esos diferentes niveles de abstracción, hágalo uso. Pero si el conjunto de herramientas no lo permite, agregue los atributos de ID e informe a los expertos de su dominio que esos son solo "atributos técnicos".

    
respondido por el Doc Brown 08.04.2014 - 16:43
4

La mayoría de las veces, el campo ID del que está hablando lo generará la base de datos, por ejemplo, como una secuencia RDBMS o un identificador único NoSQL . Por lo tanto, está vinculado al correspondiente backend de base de datos utilizado.

De acuerdo con el Principio de persistencia Ignorancia / poligloto persistencia , deberías ocultar mejor este ID de tus agregados de dominio, ya que tanto como sea posible.

En la práctica, es posible que los agregados de su dominio ya tengan un identificador único. Por ejemplo, un número de serie, un código de cliente, un nombre de inicio de sesión, un número de cuenta, una referencia de factura o un ISBN para un libro.

Si no hay tal identificador "natural" en su modelo, puede ser una función de la lógica de dominio para generar dichos identificadores genuinos, por ejemplo. siguiendo un patrón definido por la regulación, o nociones amigables con el ser humano, siguiendo las mejores prácticas de su compañía (es común incluir el año y el mes en los números de factura, o un identificador alfanumérico del departamento a cargo del proceso, por ejemplo).

Dentro de Infrastructure Layer , probablemente permitiría que aparezca un campo ID , especialmente si necesita construir consultas de SQL unidas entre varias tablas RBDMS. O, si usa un ORM, no puede persistir directamente los objetos agregados DDD como objetos ORM, sino usar una capa de traducción "agnóstica". Esto es, por ejemplo, lo que propone nuestro marco DDD , agregando un capa de traducción entre los objetos planos DDD y los objetos ORM, que tienen su propia ID ... algún tipo de "ORM cuadrado": en el asignador DDD sobre un asignador ORM.

DDD se trata principalmente de aislamiento : ¡no contamine su dominio con la consideración de la base de datos! Nombrar un campo de objeto agregado como ID definitivamente huele: probablemente haya otra denominación, compatible con el Ubiquitous Language de su contexto acotado, que se puede usar en lugar de un simple ID .

    
respondido por el Arnaud Bouchez 12.10.2015 - 15:36
0

No creo que la identificación sea un artefacto de base de datos. ¿Cómo sabes que la cuenta con la que estás trabajando es correcta? Sabes que es una cuenta correcta porque probablemente tiene un identificador único. En su caso, el identificador único se llama "Id", por lo que, naturalmente, usted piensa que es un artefacto de base de datos. Debido a esto, creo que está perfectamente bien tener una propiedad de identificación en el modelo de su dominio.

En una nota al margen, NO tendría una propiedad de clave externa en un modelo de dominio. Por ejemplo, en lugar de tener AddressId en el modelo de dominio, tendría una propiedad de Dirección y esa contendría la ID de la dirección.

    
respondido por el CodeART 08.04.2014 - 16:52

Lea otras preguntas en las etiquetas