DDD y el uso de Getters y Setters

Question

He leído algunos artículos/publicaciones sobre el uso de Getters y Setters, y cómo ayudan a vencer el propósito de la encapsulación en objetos de modelo de dominio. Entiendo la lógica detrás de no usar setters: está permitiendo que el código del cliente manipule los atributos de ese objeto, fuera del contexto de las reglas de negocio objeto e invariantes.

Ahora, este principal todavía me confunde. Por ejemplo, ¿qué sucede si necesito cambiar el valor de una variable miembro de un objeto? Por ejemplo, si el nombre de una persona cambia, ¿cómo puedo reflejar esto en el modelo? Al principio pensé, bueno, ¿por qué no tener una función llamada 'ChangeName' que me permite pasar el nuevo nombre y, a su vez, puede cambiar la variable interna de 'nombre'. Bueno ... eso es solo un colocador ¿no?

Lo que necesito aclarar: si tuviera que eliminar por completo a los incubadores, entonces en situaciones como las anteriores, ¿se supone que debo confiar únicamente en los parámetros del constructor? ¿Debería pasar el nuevo valor de atributo en lugar del antiguo valor de atributo a través de un constructor, después de lo cual puedo persistir en los cambios pasando el objeto a la infraestructura de persistencia que tengo?

Estos dos artículos son útiles en esta discusión:

1. http://kellabyte.com/tag/ddd/
2. http://typicalprogrammer.com/?p=23

Answer 1

Bueno, esto es una discusión clásica. Hay varios otros hilos aquí en Stack Overflow sobre esto.

Pero. Get/Set's (¿Propiedades automáticas?) No son todas malas. Pero tienden a hacer que construyas tus entidades como contenedores de datos "muertos" que solo tienen prop y no métodos. Los signos de esto a menudo se llaman dominio anémico y tienen muy poco comportamiento. Mi recomendación es:

1. Intenta usar prop lo menos posible.
2. Trate de encontrar grupos de datos que pertenecen juntos y DEBERÍA ser juntos como ej. Primer nombre Segundo nombre y apellido. Otro ejemplo es Zipcode, City, Street. Es mejor establecer estos datos a través del método . Minimiza las posibilidades de que su entidad sea inválida.
3. A menudo los datos que pertenecen juntos se pueden agrupar como un objeto de valor .
4. Más objetos de valor tienden a mostrar más métodos descriptivos de su entidad que son "verbos" en lugar de sus entidades generalmente "sustantivos" .
5. Más métodos para sus objetos de valor también se abren para agregar más comportamiento y tal vez reducir sus servicios "gordos" (tal vez usted no tiene servicios con demasiada lógica de negocios filtrada ...).

Hay más para decir aquí ... pero una respuesta corta. Acerca de establecer datos en el constructor: solo hago eso si esta entidad no puede "vivir"/existir sin esos datos. Para la persona de la entidad, diría que quizás el nombre no sea tan importante. Pero el Número de Seguridad Social puede ser un candidato para datos de constructor. O entidad El empleado debe tener una empresa en el constructor, simplemente porque un empleado debe pertenecer a una empresa.