La responsabilidad única (razón para cambiar) de una entidad debe ser identificarse de manera única, en otras palabras, su responsabilidad debe ser localizable.
El libro DDD de Eric Evan, pág. 93:
La responsabilidad más básica de las entidades es establecer la continuidad para que el comportamiento pueda ser claro y predecible. Lo hacen mejor si se mantienen libres. En lugar de enfocarse en los atributos o incluso en el comportamiento, elimine la definición del objeto Entity hasta las características más intrínsecas, particularmente aquellas que lo identifican o se usan comúnmente para encontrarlo o combinarlo. Agregue solo el comportamiento que sea esencial para el concepto y los atributos que requiere ese comportamiento.
Más allá de eso, busque eliminar el comportamiento y los atributos en otros objetos asociados con la Entidad central. Más allá de los problemas de identidad, las Entidades tienden a cumplir con sus responsabilidades coordinando las operaciones de los objetos que poseen.
1)
... elimine la definición del objeto ENTITY hasta las características más intrínsecas, particularmente aquellas que lo identifican o se usan comúnmente para encontrarlo o combinarlo. Agregue solo un comportamiento que sea esencial para el concepto ...
Una vez que a una entidad se le asigna una identificación única , se establece su identidad y, por lo tanto, supongo que dicha entidad no necesita ningún comportamiento para mantener su identidad o ayudarla a identificarse . Por lo tanto, no entiendo qué tipo de comportamiento es el autor se refiere a (además findy match operaciones ) con " el comportamiento que es esencial para el concepto "?
2)
... elimine la definición del objeto ENTITY hasta las características más intrínsecas, particularmente aquellas que lo identifican o se usan comúnmente para encontrarlo o combinarlo. ... Más allá de eso, busca eliminar el comportamiento y los atributos en otros objetos asociados con la ENTIDAD central.
Entonces, cualquier comportamiento que no ayude a identificar la entidad, pero aún así caracterizaríamos ese comportamiento como una característica intrínseca de esa entidad (es decir, el ladrido es intrínseco a los perros, volar es intrínseco a los aviones, poner huevos es intrínseco a las aves ... .), debe colocarse en otros objetos asociados con esa entidad (ejemplo: debemos poner el comportamiento de ladrar en un objeto asociado con una entidad de perro)?
3)
Más allá de eso, busque eliminar el comportamiento y los atributos en otros objetos asociados con la ENTIDAD central.
a) MyEntitydelega responsabilidades A_respy B_respobjetos ay b, respectivamente.
A pesar de que la mayor parte de A_respy B_resptrabajo es realizado por ay bcasos, los clientes están siendo servidos A_respy B_respa través de MyEntity, lo que significa que desde la perspectiva del cliente las dos responsabilidades pertenecen a MyEntity. Por lo tanto, no significa eso MyEntitytambién tiene A_respy B_respresponsabilidades y, como tal, está violando SRP ?
b) Incluso si asumimos eso A_respy B_respno pertenecemos MyEntity, MyEntitytodavía tiene la responsabilidad AB_respde coordinar las operaciones de los objetos ay b. Entonces, ¿no MyEntityviola SRP ya que como mínimo tiene dos responsabilidades : identificarse de manera única y también AB_resp?
class MyEntity
{
private A a = ...
private B b = ...
public A GetA()
{ ... }
public B GetB()
{ ... }
/* coordinates operations of objects a and b */
public int AworkB()
{ ... }
}
/* A encapsulates a single responsibility resp_A*/
/* A is value object */
class A
{ ... }
/* B encapsulates a single responsibility resp_B*/
/* B is value object */
class B
{ ... }
ACTUALIZAR:
1)
El comportamiento en este contexto se refiere al comportamiento semántico. Por ejemplo, una propiedad en una clase (es decir, un atributo en un objeto de dominio) que se usa para identificarla de forma exclusiva tiene un comportamiento. Si bien esto no está representado en el código directamente. El comportamiento esperado es que no habrá valores duplicados para esa propiedad.
Entonces, en el código, casi nunca necesitaríamos implementar realmente un comportamiento (es decir, una operación) que de alguna manera mantendría la identidad de la entidad, ya que como usted explicó, dicho comportamiento solo existe como un concepto en un modelo de dominio (en forma de un atributo ID de una entidad), pero cuando traducimos este atributo de ID en código, se pierde parte de su semántica (es decir, se pierde la parte que implícitamente se asegura de que el valor de ID sea único).
2)
Además, una propiedad como Age no tiene contexto fuera de una Entidad Persona y, como tal, no tiene sentido moverse a un objeto diferente ... Sin embargo, esa información podría almacenarse fácilmente en una ubicación separada que el identificador único, de ahí el referencia confusa al comportamiento. La edad podría ser un valor cargado flojo.
a) Si la Agepropiedad está cargada de manera diferida, ¿podemos llamarlo un comportamiento, aunque semánticamente Agesea solo un atributo?
3)
Fácilmente podría tener operaciones específicas de Dirección, como la verificación de que es una dirección válida. Puede que no lo sepas en el momento del diseño, pero todo este concepto es descomponer los objetos en sus partes más pequeñas.
Si bien estoy de acuerdo en que perderíamos el contexto al movernos Agea un objeto diferente, el contexto no se perdería si moviéramos la DateOfBirthpropiedad a un objeto diferente, pero generalmente no lo movemos.
¿Cuál es la razón principal por la que nos moveríamos Addressa otro objeto, pero no DateOfBirth? ¿Porque DateOfBirthes más intrínseco a la Personentidad o porque hay menos posibilidades de que en algún momento en el futuro necesitemos definir operaciones específicas para DateOfBirth?
4. debo decir que todavía no sé si MyEntitytambién tiene A_respy B_respresponsabilidades y por eso MyEntitytambién haber AB_respno se considera una violación de SRP
EULERFX
1)
Los comportamientos a los que se refiere el autor son comportamientos asociados con la entidad. Estos son los comportamientos que modifican el estado de la entidad.
a) Si te entiendo correctamente, ¿estás diciendo que la entidad solo debe contener esos comportamientos que modifican sus atributos (es decir, su estado )?
b) ¿Y qué hay de los comportamientos que no necesariamente modifican el estado de la entidad , pero que aún se consideran como una característica intrínseca de esa entidad (ejemplo: ladrar sería una característica intrínseca de una Dogentidad, incluso si no se modificara) Estado del perro )? ¿Deberíamos incluir estos comportamientos en una entidad o deberían trasladarse a otros objetos?
2)
En cuanto al comportamiento de movimiento a otros objetos, el autor se refiere específicamente a objetos de valor.
Aunque mi cita no lo incluye, pero el autor menciona en el mismo párrafo que en algunos casos los comportamientos (y los atributos ) también se trasladarán a otras entidades (aunque entiendo los beneficios de trasladar los comportamientos a las VO)
3) Suponiendo que MyEntity(vea la pregunta 3. en mi publicación original) no viola SRP, diríamos que una responsabilidad de MyEntityentre otras cosas también comprende:
a. A_resp + B_resp + AB_resp ( AB_respcoordina objetos ay b)
o
si. AB_resp + delegar A_respy B_respa objetos ( ay b) asociados con MyEntity?
4) El libro DDD de Eric Evan, pág. 94:
CustomerID es el único identificador de la ENTIDAD del cliente (figura 5.5), pero el número de teléfono y la dirección a menudo se utilizan para encontrar o hacer coincidir un Cliente. El nombre no define la identidad de una persona, pero a menudo se usa como parte de los medios para determinarlo.
En este ejemplo, los atributos del teléfono y la dirección se trasladaron al Cliente, pero en un proyecto real, esa elección dependería de cómo los clientes del dominio suelen coincidir o distinguirse. Por ejemplo, si un cliente tiene muchos números de teléfono de contacto para diferentes propósitos, entonces el número de teléfono no está asociado con la identidad y debe permanecer con el contacto de ventas.
un)
CustomerID es el único identificador de la ENTIDAD del cliente (figura 5.5), pero el número de teléfono y la dirección a menudo se utilizan para encontrar o hacer coincidir un Cliente. El nombre no define la identidad de una persona, pero a menudo se usa como parte de los medios para determinarlo.
La cita establece que solo los atributos asociados con la identidad deben permanecer en una entidad . Supongo que autor significa que la entidad debe contener solo aquellos atributos que a menudo se usan para encontrar o coincidir con esta entidad , mientras que TODOS los demás atributos deben moverse.
b) ¿Pero cómo / dónde se deben mover otros atributos ? Por ejemplo (se supone que el atributo de dirección no se usa para buscar o coincidir Customer y, por lo tanto, queremos mover el atributo de dirección fuera de Customer):
si en lugar de tener Customer.Address(de tipo string) creamos una propiedad Customer.Addressde tipo Address, ¿movimos el atributo de dirección a un objeto VO asociado (que es de tipo Address) o diríamos que Customertodavía contiene el atributo de dirección ?
C)
En este ejemplo, los atributos del teléfono y la dirección se trasladaron al Cliente, pero en un proyecto real, esa elección dependería de cómo los clientes del dominio suelen coincidir o distinguirse. Por ejemplo, si un cliente tiene muchos números de teléfono de contacto para diferentes propósitos, entonces el número de teléfono no está asociado con la identidad y debe permanecer con el contacto de ventas.
El autor no está equivocado aquí, ya que si asumimos cada uno de los muchos números de teléfono de contacto que Customersolo pertenecen a ese particular Customer, entonces diría que estos números de teléfono están asociados con la identidad tanto como cuando Customersolo tenía un número de teléfono ?
5)
La razón por la que el autor sugiere desmantelar la entidad es que cuando uno crea inicialmente una entidad de Cliente, existe la tendencia de llenarla con cualquier atributo que se pueda pensar que está asociado con un cliente. Este es un enfoque centrado en los datos que pasa por alto los comportamientos que finalmente conducen a un modelo de dominio anémico.
Fuera de tema, pero pensé que el modelo de dominio anémico resulta de mover el comportamiento fuera de una entidad , mientras que su ejemplo es poblar una entidad con muchos atributos , lo que resultaría en Customerun comportamiento excesivo (ya que probablemente también incluiríamos en Customerlos comportamientos que modificar estos atributos adicionales ) y por lo tanto en violación de SRP?
Gracias