Bueno, como la respuesta a Julio la tengo más o menos elaborada, voy a utilizar código ajeno para explicarme. A ver si queda suficientemente claro. El código completo está disponible en el ejemplo “oficial” de DDD: DDDSample. Lo podéis bajar desde el repositorio de subversion (yo he utilizado la última versión etiquetada como 1.1.0) o podéis “navegar” por el código fuente coloreado e hipervinculado generado con el plugin maven jxr. Seguramente explicar este ejemplo daría para varios blogs, pero me voy a centrar en la explicación de la persistencia. Si queréis ver los ficheros de configuración de Spring e Hibernate no os quedará más remedio que acceder al SVN. Perdonad que no os hipervincule todas las clases pero ya os he explicado que ando justito de tiempo libre…

Este DDDSample es la implementación del ejemplo empleado por Eric Evans en el libro azul y que se trata de una compañía de transporte de contenedores. Yo voy a seguir el camino de una petición de reserva del envío de un contenedor, que es algo sencillo pero que implica guardar datos en la base de datos. No voy a entrar en cómo se llama desde la UI al servicio para no extenderme demasiado, pues como dije más arriba tenéis todo el código disponible para descargarlo, pero sí que os explicaré (al final) el “truqui” que emplean aquí por si os suena un poco raro.

Todo empieza por una fachada llamada BookingServiceFacadeImpl (que implementa la interfaz BookingServiceFacade y que no sirve para otra cosa que para envolver al “verdadero servicio” (BookingServiceImpl, que implementa BookingService). El constructor de BookingServiceImpl tiene como parámetros un CargoRepository, un LocationRepository y un RoutingService, esto se podría cambiar por un constructor vacío y varios setters, pero siempre y cuando nos aseguremos de no usar BookingService sin antes haber “seteado” estos colaboradores. Por eso es más seguro inyectar los colaboradores imprescindibles en el constructor. En DDDSample se hace con Spring en context-application.xml:

El método que nos interesa es bookNewCargo:

@Override@Transactionalpublic TrackingId bookNewCargo(final UnLocode originUnLocode,                             final UnLocode destinationUnLocode,                             final Date arrivalDeadline) {// TODO modeling this as a cargo factory might be suitablefinal TrackingId trackingId = cargoRepository.nextTrackingId();final Location origin = locationRepository.find(originUnLocode);final Location destination = locationRepository.find(destinationUnLocode);final RouteSpecification routeSpecification = new RouteSpecification(origin, destination, arrivalDeadline);

final Cargo cargo = new Cargo(trackingId, routeSpecification);

cargoRepository.store(cargo);logger.info("Booked new cargo with tracking id " + cargo.trackingId().idString());

return cargo.trackingId();}

Fijaos que no hablamos con la BD para guardar el objeto Cargo que recién creamos, sino que hablamos con un CargoRepository: el que hemos inyectado en el constructor y que puede perfectamente guardar el objeto en la BD o en cualquier otro sitio, p.ej. una Collection. ¿Por qué no? Si no hubiera un requisito que nos pidiera poder recuperar la información de los envíos (Cargos) si la aplicación se reiniciara, no habría nada que nos impediría mantener en memoria esta información. ¿Verdad? En esto justamente consiste la ignorancia de la persistencia. Si cambiamos la política para guardar los datos, el código de los objetos Cargo no necesita ser modificado ni una línea. Es más, nuestro servicio (de dominio) BookingService tampoco. Sólo necesitamos cambiar el repositorio que inyectamos. Esto es fácil con Spring. Veamos cómo está hecho en context-infrastructure-persistence.xml:

No pongo los detalles de cómo se configuran transactionManager ni sessionFactory porque no son significativos: son idénticos a los de cualquier otra aplicación. Lo que sí es relevante aquí es CargoRepositoryHibernate. Fijaos en que está anotada con @Repository y extiende HibernateRepository (que simplemente sirve para tener el setSessionFactory y el getSession). Finalmente, echemos un vistazo al método store que es el que nos interesa ahora, pero echad un vistazo “de refilón” a los demás porque pueden ayudaros a situaros sobre cuál es la responsabilidad de este objeto (que es MUY parecido a un DAO).

public void store(Cargo cargo) {getSession().saveOrUpdate(cargo);// Delete-orphan does not seem to work correctly when the parent is a componentgetSession().createSQLQuery("delete from Leg where cargo_id = null").executeUpdate();}

Observad que alguien ha dejado un comentario explicando el borrado de ciertos objetos relacionados. Esto tiene un cierto “tufillo”, yo hubiera extraído el comentario y la linea a la que se refiere a un método private llamado deleteOrphansWhenParentIsAComponent o algo así, y hubiera llevado el comentario al javadoc del método y me aseguraría de tener un buen test para esto que huele tan raro… pero es lo que hay…

Llegados a este punto algunos volveréis la vista atrás y diréis: “¡Demonios! ¿Dónde hace commit?”. Aquí es donde tenemos que mostrar todas las cartas y enseñar dónde se configura aquella fachada de la que hablábamos al principio BookingServiceFacadeImpl:

  
    
 
 
      hibernateInterceptor           
 
 
 
 

Claro, ahora se entiende, usamos el HibernateInterceptor con la misma sessionFactory de nuestros repositorios. Je, je… Vale, es un poco “truqui”, pero es la manera más limpia que hay de trabajar “puertas adentro” y olvidarte de historias.

¡Uy! Se me olvidaba explicar cómo es el objeto Cargo, que es lo que en DDD se denomina AggregateRoot y que es algo así como la raíz de un árbol de objetos dependientes, cuya existencia depende de la raiz. En este caso son Cargo, Itinerary, Leg, Delivery y RouteSpecification. No voy a profundizar aquí, pero diré que cuando guardamos un Cargo podemos estar guardando todos los que dependen de él. Cargo también es una Entity (en el sentido de DDD y también en el sentido de JPA, si lo usáramos).

¿Cómo se mapea este AggregateRoot con las tablas de la BD? Si usáramos JPA sería muy fácil viendo las anotaciones; en el caso de DDDSample han usado los ficheros de mapeo de Hibernate. No voy a entrar en detalles sobre esto porque sería explicar Hibernate, y no es mi intención ahora mismo.

Por último, el “truqui” del que os hablaba al principio que usan para exponer la fachada. Usan RmiServiceExporter, una utilidad (como otras muchas) de Spring, y que permite acceder a este objeto BookingServiceFacadeImpl como si de un EJB se tratara. Fácil, ¿verdad? Bueno, también podríais haberlo anotado con @EJB y todas esas cosas que explican en Java EE. Ya se sabe, para gustos, colores.

Espero que haya quedado claro el “meollo” de la cuestión, que tiene mucho que ver con aquello que contaba hace ya bastante sobre la Arquitectura en Capas de Cebolla. La idea que me gustaría que os quedara después de este artículo (y sobre todo el anterior) es que la ventaja de hacer un modelo de dominio rico y carente de dependencias tecnológicas consiste en que tenemos un código más limpio y realmente desacoplado, lo que nos trae un montón de ventajas como que podemos comprobar unitariamente nuestro código con mucho menos coste y riesgo de errores.

Quedo a vuestra disposición para discutir lo que creáis conveniente.

Nota: Perdonad el formato de los xml, pero Blogger me reformatea los elementos vacíos y me monta un cristo, hasta que me he dado cuenta y los he cambiado a mano.

Gojko Adzic es un tipo que habla en inglés con un acento balcánico realmente difícil de seguir (al menos para mi), así que pensé que era buena idea comprar el libro para entender a qué se refiere cuando habla de talleres de especificaciones y de pruebas de aceptación ejecutables en entornos ágiles. Además, Gojko Adzic también imparte cursos sobre Domain-Driven Design y esa relación entre DDD y pruebas de aceptación es algo que me interesa bastante.

Voy a ser sincero, también compré el libro porque es el primero en el que se habla de Concordion, la herramienta open source en la que modestamente colaboro. Pero son apenas unas páginas y el valor del libro es mucho más que eso.

Adzic explica la importancia de que “la gente del negocio” hable el mismo idioma que “la gente técnica”. Esto muchos lo entienden como obligar a clientes y usuarios a que hablen en términos tecnológicos como “altas, bajas, modificaciones y listados (CRUD en inglés)”, o peor aún, de tablas, campos y relaciones.

En DDD hablamos de un lenguaje ubícuo, o único en todo el proyecto, y que es el que usan tanto técnicos como usuarios. Esto permite reducir los defectos producidos por malentendidos y tiende puentes entre ambos mundos, abriendo la posibilidad a una verdadera colaboración.

Un inciso melancólico. Voy ahora mismo montado (mientras escribo estas notas en mi moleskine) en el metro ligero y me he acordado de ese par de meses intensos que viví y trabajé (sobre todo lo primero) en Melbourne (Australia). Allí fui usuario del “tram” y he de decir que me parece un medio de transporte público de lo más interesante porque es a la vez rápido, cómodo y silencioso.

Pero sigamos con el libro. El grueso del mismo se basa en hablar del “agile acceptance testing” y de cómo buscamos ponernos de acuerdo en qué es lo que hay y lo que no hay que desarrollar. Para esto usamos ejemplos realistas en vez de requisitos abstractos. “Los ejemplos demuestran cómo debería actuar el sistema y cómo debería ayudar a los usuarios a hacer su trabajo”. Adzic propone que estos ejemplos sean creados por todo el equipo de implementación, no sólo por un “experto del dominio” (también conocido como “analista de negocio”) como en modelos de desarrollo más tradicionales. “Usamos los ejemplos para discutir el dominio y asegurarnos de que no hay malentendidos”.

Según Adzic, el uso de ejemplos realistas obliga a pensar más acerca de los problemas. De hecho, comenta cómo se producen muchas discusiones entre los expertos cuando se plantean ejemplos para casos extremos; discusiones que incluso les hacen a veces revisar sus propios procesos de negocio. ¡Vaya! Si resulta que podemos ayudar a nuestros clientes en vez de simplemente observar su comportamiento “desde fuera”, como si fueramos “supernanis con corbata”.

Damned! ¡Me he saltado una parada! Estaba tan concentrado… Menos mal que la frecuencia del metro ligero éste es alta y he podido llegar sólo un par de minutos tarde. Buff…

De vuelta del estupendo curso de Ángel Medinilla, sigo con el resumen del libro y me fijo en que no he explicado esto de los ejemplos. Vamos, que no he puesto ejemplos de ejemplos. Adzic pone un ejemplo en la página 45 de una regla de negocio relacionada con el descuento que le podemos ofrecer a un cliente, pero a mi me gusta más el que explica David Peterson en la web de Concordion. Es bastante más completo porque nos lleva desde la historia de usuario (el requisito) hasta la prueba de aceptación automatizada (en forma de ejemplos). Es interesante cómo David hace mucho hincapié siempre en que debemos especificar con ejemplos que expliquen comportamientos muy elementales y dejar para otras especificaciones todo aquello que quedaría fuera. Son los “Further details” en el ejemplo. También Adzic habla de esto en su libro, pero menos; y yo creo que es importante esta anotación al margen para aquellos que queráis “tomar este camino” para hacer pruebas de aceptación.

En “Bridging the communication gap” también se explica cómo conducir estas reuniones (talleres de especificación) e incluso aconseja sobre algunas herramientas. Pero creo que es interesante explicar cómo pueden encajar estos talleres en nuestro calendario semanal (ágil).

Adzic sugiere lo siguiente:

Release es todo aquello que hacemos después de la demo para dejar bien cerrado el sprint. Etiquetamos en subversion, hacemos copias de seguridad, ponemos las versiones del nuevo sprint en los pom.xml (si usamos Maven y si es que tenemos que cambiar de versión), limpiamos las pizarras… y mientras esto lo pueden ir haciendo algunos desarrolladores (típicamente los becarios, je, je) pues el resto puede estar preparando el sprint primero revisando el backlog y luego, ya con los becarios incorporados, estimando las historias y decidiendo lo que se podrá hacer razonablemente en el sprint (las próximas dos semanas).

Ojo, es una manera de organizar el trabajo durante un sprint, pero lo importante de esto es que el dueño del producto (también conocido como jefe de proyecto, analista de negocio, o incluso tester, según vuestro “mapeo” preferido) se encarga de trabajar las historias de usuario (redacción y priorización) y de los ejemplos (criterios de aceptación) antes de los talleres de especificación, pero realmente es el equipo en su totalidad quien acuerda lo esencial de los criterios de aceptación mediante la discusión que se ofrece en esta reunión. Para los que ya estéis algo picados con esto del agilismo, me permito recordar “las tres Ces” (card, conversation, confirmation). Éste es el momento ideal para la conversación, aunque ya se haya tenido una conversación previa cuando se han estimado las historias de usuario en el Sprint Planning Meeting (usando terminología Scrum).

Bueno, y hasta aquí hemos llegado. Espero que os resulte útil. Y si alguien más se ha leido este libro y quiere contrastar aquí su opinión, estaré encantado de poder charlar con vosotros porque mi intención es preparar una presentación (o un taller, ya veré) sobre este tema y exponerla bajo el “paraguas” de Agile Spain.

En los últimos días he estado cruzando algunos mensajes en el blog de Julio César Pérez Arques y dado que hemos llegado a un punto donde no lo puedo “despachar” con un par de frases ocurrentes, creo que lo oportuno es explicarlo en un formato más “extenso”.

En un artículo de su blog, Julio César resumía bastante bien una presentación de Neal Ford en InfoQ, pero dijo algo que nos llevó a iniciar esa “eterna” discusión sobre modelo anémico y modelo rico:

No me gustan nada los constructores con más de 2 parametros. Prefiero uno vacio y luego hacer sets.

Julio César en realidad luego explica la postura de Neal Ford sobre el uso de constructores, más alineada con los modelos ricos que con los modelos anémicos que defiende Julio.

Y ante mi crítica, Julio se excusa (en vano, je, je) diciendo lo siguiente:

No se si es que estoy demasiado Springizado pero me gusta más tener mi capa service y mi capa dao separaditas. Supongo que también tiene que ver con el tipo de aplicaciones en las que trabajo, basicamente de gestión sobre una bbdd ama y señora.
¿Por qué acaso en una aplicación de gestión no son todas las clases del modelo Value Objects? Para mi la unica diferencia es en si mueven los datos del cliente a la app o si de la app a la bbdd. Siempre desde mi pto d vista…

No voy a entrar a discutir si usar Spring y tener las capas de servicios y de acceso a datos desacopladas tienen algo que ver. Para mi no, pero no me interesa discutir ahora sobre frameworks, porque me interesa “atacar” esa idea de que una “aplicación de gestión” es poco más que una aplicación de “data entry”. No estoy de acuerdo. Para nada, una aplicación de gestión es justamente donde más y mejor podemos aplicar el Domain-Driven Design.

Pero voy a usar un viejo artículo de Udi Dahan (al que, sí, es cierto, últimamente cito mucho) en el que explica muy, muy bien cómo y por qué debemos orientar nuestros diseños hacia el modelo de dominio en vez de al CRUD.

Udi pone el ejemplo de un sistema para hacer entrevistas a candidatos en una selección de Recursos Humanos. Y así, si modelamos esta aplicación como un conjunto de inserciones, actualizaciones y eliminaciones de objetos Cita, nuestro código para el servicio de citar a un entrevistado sería algo así como:

Cita cita = new Cita();

cita.setEntrevistador(entrevistador);entrevistador.getCitas().add(cita);

cita.setCandidato(candidato);candidato.getCitas().add(cita);

cita.setFechaHora(fechaHora);

dao.guardar(cita);

Pero, en cambio, si nos orientamos al dominio y modelamos el sistema como objetos con estado que se encargan ellos mismos de persistirse cuando cambian de estado (si es necesario), conseguimos que el código de nuestros servicios no sólo no esté acoplado al modelo de datos sino que es más fácil de entender al carecer de artificios tecnológicos:

entrevistador.planificaEntrevistaCon(candidato).enFechaHora(fechaHora);

Si entramos a discutir cómo se implementan estos métodos, a partir de este punto tendremos una gran discusión porque no todos se ponen (nos ponemos) de acuerdo sobre cómo hay que hacerlo. Muchos hablamos de la ignorancia de la persistencia, es decir, de que los objetos de dominio no deben llamar nunca a los DAOs directamente sino que para ello hablan con los Repositorios usando una interfaz tipo Collections. Otros dicen que por qué esa indirección si el 99% de las aplicaciones tienen que persistir los datos. Yo tengo claro que se trata de aplicar los principios SOLID y que, por tanto, lo correcto es desacoplar la lógica de negocio de la lógica de persistencia. Pero para gustos hay colores…

Esta semana lo voy a tener un poco difícil, pero puede que para la semana que viene pueda implementar completo este ejemplo usando Spring y JPA. Espero que la salud mía y de mis niños me lo permita. Je, je…

Para terminar, si a alguien le interesa todo esto del Diseño Orientado al Dominio, le invito a pasarse por la lista de DDD-es que hemos creado recientemente.

En ocasiones he participado en la lista en inglés sobre DDD, pero es un grupo muy maduro donde a veces el idioma me dificulta las discusiones. Ya saben, ellos bromean contigo haciendo un juego de palabras y tú no sabes siquiera de qué va la cosa… Creo que tener un foro donde expresarnos sin las cortapisas del lenguaje nos ayudará a aprender más rápido y mejor sobre Diseño Basado en el Dominio.

También estoy en el grupo de LinkedIn, pero no siento la necesidad de crear otro en español.

En fin, espero que los que os vayáis uniendo a este foro os presentéis (si así lo deseáis) y que os sintáis libres para preguntar o aportar lo que queráis.

• los servicios son autónomos
• los límites son explícitos
• los servicios comparten esquemas y contratos, no clases
• la compatibilidad de un servicio se determina en base a una política

y se centra en la autonomía de los servicios. Nos explica cómo alcanzar esa autonomía de una manera genuína, llegando hasta el extremo de que cualquier servicio se pueda implementar con el diseño que se quiera y sin la obligación de compartir siquiera la misma base de datos.

- ¡Eh! ¿Qué ha dicho? ¿Qué no se comparte la base de datos?
- ¿Y qué pasa con las restricciones de integridad? ¿Qué hago con mis foreign keys?

Muchos le preguntaron a Udi por esto. Je, je, yo ya sabía por dónde iba él porque esta discusión me la conozco de cuando estaba en Degesys, aunque allí no llegamos a ninguna conclusión (al menos mientras yo estuve). El caso es que la respuesta es bien fácil: las restricciones de integridad en la base de datos sólo sirven para acoplar servicios entre sí. Así que tú verás si quieres estar acoplado o no… Claro, para conseguir esta autonomía hay hacer concesiones:

• no tenemos un único modelo de datos compartido por todos los servicios
• no tendremos un estado coherente de los datos al que estamos acostumbrados
• tendremos que asumir un cierto nivel de redundancia en nuestros datos almacenados

¿Cómo se consigue esto? Pues Udi lo resuelve de una manera muy sencilla a la vez que elegante:

• los datos son “propiedad” de una única fuente autorizada, es decir, cada dato en la base de datos sólo es manipulado por un único servicio
• los servicios interesados en algún dato se suscriben a los cambios que publicará su fuente autorizada y guardan una copia local del dato (a modo de caché)

Esto, si no estoy equivocado, se viene conociendo como Event-Driven Architecture (EDA).

Pero Udi no nos contó sólo que la manera de implementar SOA es haciendo EDA, sino que insistió en que un servicio debe ser concebido desde el negocio y que se implementa íntegramente desde la UI hasta la BD. Para ello nos explicó diferentes maneras de componer la UI, pero todas evitando el concepto de página monolítica. Y recalcó que no tenemos que tener una única capa técnica consistente, sino que podemos decidir usar diferentes soluciones técnicas para cada problema de negocio. Claro, lo difícil es que hay que acertar en definir los “bounded contexts”, y sólo podremos acertar si tenemos claro que éste no es un trabajo tecnológico sino de análisis del negocio.

- ¡Vaya, claro, por eso hablan tanto del alineamiento de IT con el negocio cuando se hace SOA!
- ¡Ahora lo entiendo!
- ¡Y yo que pensaba que todo esto de SOA iba de reusar componentes tecnológicos y poner webservices por doquier!

Si estáis interesados, otro día puedo recopilar más notas y recordar algunos de los ejemplos que usó Udi en el curso.

¡Ah! Y que no se me olvide. Gracias a Hadi por el detalle que tuvo conmigo para Agile Spain. Lo dejo ahí porque si queréis enteraros tendréis que asistir a la charla que darán Juan, Agustín y Leo sobre “Introducción a Scrum”.

Es bastante evidente el porqué de su nombre (incluso en español).

No voy a hacer un refrito del artículo original ni de su traducción, pero sí os diré dos cosas:

1) que me parece especialmente relevante el comentario en la tercera parte del artículo original (lo siento, sólo en inglés) sobre qué es lo que está en el “corazón” de la cebolla: el modelo de dominio y NO el modelo de datos,
2) que he estado contrastando esta arquitectura (que no se queda en la mera representación visual de la misma) con la aplicación de demostración de DDD y, salvo algún detalle menor, encaja perfectamente y hace más fácil de entender el por qué de ciertas dependencias.

Como siempre, vuestros comentarios serán bienvenidos.

El caso es que he copipegado código del ejemplo de editor multipáginas que viene con Eclipse y también del WicketBench (un plugin para trabajar con Wicket del que pretendo plagiar más de una idea). Y resulta que este código “heredado” hace un uso bastante prolijo de métodos estáticos para obtener información de contexto y, sobre todo, de la plataforma. Y me viene al pelo el reciente artículo de Misko Hevery donde explica por qué los métodos estáticos son tan malos para las pruebas y delatan diseños deficientes.

En resumen: no tengo pruebas unitarias de mi código porque no puedo sustituir las llamadas a métodos estáticos por ningún tipo de doble. Cualquier colaborador puedo sustituirlo más o menos fácilmente con un doble (p.ej. un mock), pero un método estático está pegado “a fuego” a una clase, y no puedo sustituir una clase por otra…

Claro está que estoy cambiando el código para encapsular las llamadas a métodos estáticos en clases de colaboración que pueda sustituir en mis pruebas. Así acoto el problema, tal y como Eric Evans aconseja al explicar el “anticorruption layer” (capa anticorrupción), y mejoro la facilidad para escribir pruebas para mi diseño y, por tanto, mejoro también mi diseño.

Durante 1 hora da para decir muchas cosas, pero yo me quedaría con lo siguiente:

Construir puentes
En vez de tener a los analistas yendo y viniendo entre los usuarios y los técnicos (la brecha), es mejor conseguir que la organización permita establecer puentes entre ambos mundos. Aquí insisten en la importancia vital de las conversaciones entre usuarios y técnicos porque ayudan a evitar trabajar en funcionalidades que no aportan valor de negocio y además permiten encontrar mejores soluciones que trabajando a través de intermediarios.

Fatalidad
Si creemos que no es posible construir esos puentes, estaremos de alguna manera influyendo en nuestro entorno para que la brecha se siga manteniendo e incluso se amplíe. Así se defienden unas partes de otras mediante contratos, documentos de requisitos, diagramas de arquitectura… En cambio, si la actitud es positiva, es posible colaborar en un entorno de confianza en la que incluso se pueda trabajar en construir un sistema sin conocer cómo será el “desplegable” final.

Lenguaje ubicuo
Para que todos dentro del equipo (gente de negocio y gente técnica) puedan entenderse es conveniente usar un lenguaje ubicuo (tal y como recomienda Eric Evans en su estupendo libro “Domain-Driven Design“).
Sin embargo, el uso de un lenguaje común entre usuarios y técnicos que permita y/o facilite la comunicación entre ambas orillas no debe obligarnos a que este lenguaje sea “universal” para toda la empresa. Fowler dice explícitamente que es mejor un conjunto de “modelos locales” (más manejables y comprensibles y menos abstractos) y un mecanismo de mapeo entre ellos.

Construir juntos
Técnicas como construir juntos “Prototipos de baja fidelidad” (ya sabéis, “paper prototyping” con Post-Its, etc), “Storyboards” (como los que se usan para las películas de cine),… ayudan a construir esos puentes.

Hecho
Para especificar qué entienden los usuarios y los técnicos por “tarea completada” es conveniente utilizar ejemplos, idealmente que se puedan comprobar automáticamente. (Es lo que se conoce como pruebas de aceptación ejecutables).

Suficiente
Otro término muy relacionado con “hecho” es “suficiente”. Se trata de conocer lo suficiente para avanzar hasta el siguiente paso. Para ello es necesario asumir que las prioridades están en constante cambio durante la construcción del proyecto.

Productividad
Un detalle, ¿sabíais que sólo el 15% aprox del coste total del software corresponde a la programación?
Es muy importante trabajar continuamente en encontrar todas las oportunidades posibles que nos permitan recoger reacciones (feedback) de todos los miembros del equipo y conocer aquellos factores puedan afectar al estado de ánimo del equipo puesto que éste es un aspecto psicológico que afecta significativamente a la comunicación y, por tanto, a la productividad.