Diseño impulsado por dominio, SOC y identificación de entidad

Question

He estado tratando de concentrarme en DDD y en cómo se puede relacionar con MVC, pero estoy teniendo problemas con la identificación de entidades.

En particular, trato de mantener una separación estricta entre mi presentación, dominio y modelos de datos. Mi problema aquí es cómo conservo la identificación de entidades a través de estos límites. Para aclarar, estoy usando clases separadas para representar la misma entidad en diferentes contextos, por ejemplo, tengo una clase de dominio 'ShipmentRequest', varias clases de presentación 'ShipmentRequestView' (dependiendo de las propiedades requeridas por una vista particular) y una tabla de base de datos 'shipment_request' (mi modelo de datos).

Tengo ganas de usar una propiedad 'ID' (como ShipmentRequestId) sería una violación de la separación que estoy tratando de lograr, ya que esta propiedad de ID es una preocupación de la base de datos, y no una preocupación de dominio; y no quiero pasar el mismo objeto entre capas, ya que esto significaría pasar datos innecesarios a mi capa de presentación.

¿Cómo puedo preservar esta separación, y aun así rastrear la identidad entre estas capas?

Answer 1

Sin el campo Id en su entidad, no puede asignarlo a una fila de la base de datos. Por lo tanto, este campo de ID, aunque no tenga nada que ver con sus entidades, debe filtrarse en su modelo de dominio.

Creo que a menudo es excesivo usar un modelo de presentación, especialmente si lo que está tratando de lograr es ocultar algunas propiedades.

Creo que la separación de las preocupaciones se debe principalmente al contexto delimitado. Por ejemplo, su tabla Person, PersonView y Person parecen estar relacionadas con un contexto de procesamiento de transacciones. En tal contexto, yo no haría ni siquiera tener una PersonView y la tabla de personas sería abstraída.

Por otro lado, si se encuentra en un contexto de informes, una PersonView sería más útil.

Creo que el contexto es mucho más importante que cualquier esquema de estratificación.

En cuanto a la falta de una clave natural en su entidad de persona, podría significar que la persona no es realmente una entidad. Por ejemplo, en cualquier aplicación de la vida real, siempre hay un número asociado a la persona: un empleado tiene un número de empleado, un cliente como número de cuenta, etc. Esta identificación comercial es definitivamente parte del dominio.

Answer 2

Creo que tener un campo de "ID" en las entidades es una concesión que la mayoría (¿la mayoría?) Termina haciendo, y no me sentiría culpable por hacerlo.

Como dices, incluso cuando no estés tratando con la base de datos, aún necesitas cierta noción de identidad. Puede tratar de encontrar algún tipo de identidad "natural" para cada entidad (un campo como el nombre o una combinación de varios campos), pero esto no siempre es posible. Incluso cuando lo es, tener un campo ID a menudo actúa como una forma abreviada útil para decir "la entidad cuyo nombre es X y cuya fecha de nacimiento es Y, y cuyo SSN es Z".

Al final, aunque podría decirse que es menos "puro", tener un campo de ID simplificará mucho las cosas.

Answer 3

¡La solicitud de envío es definitivamente un mejor ejemplo!

¿Cómo encontrarán los usuarios una solicitud de envío? Según la respuesta, es posible que necesite una identificación que los usuarios puedan recordar, por ejemplo 20091012-A.

¿Puede un ID de solicitud de envío cambiar alguna vez? En caso negativo, utilice la clave db para la identidad.

¿Necesitará transferir solicitudes de envío de un sistema a otro? En caso afirmativo, no use la clave db para la identidad.

Cualquiera que sea la clave que utilice, deberá ponerla a disposición en el modelo de presentación para que pueda crear vínculos a las acciones en una solicitud de envío en particular.