En mi opinión, no es así en absoluto. Y es una violación de DRY.
La idea es que el objeto de entidad / dominio en el medio está modelado para representar el dominio lo mejor y lo más conveniente posible. Está en el centro de todo y todo puede depender de él, ya que el dominio en sí no cambia la mayor parte del tiempo.
Si su base de datos en el exterior puede almacenar esos objetos directamente, entonces asignarlos a otro formato en aras de separar capas no solo no tiene sentido, sino que crea duplicados del modelo y esa no es la intención.
Para empezar, la arquitectura limpia se realizó con un entorno / escenario típico diferente en mente. Aplicaciones de servidor empresarial con capas externas gigantes que necesitan sus propios tipos de objetos especiales. Por ejemplo, bases de datos que producen SQLRowobjetos y necesitan SQLTransactionsa cambio de actualizar elementos. Si usara los del centro, violaría la dirección de dependencia porque su núcleo dependería de la base de datos.
Con ORM livianos que cargan y almacenan objetos de entidad, ese no es el caso. Ellos hacen el mapeo entre su SQLRowdominio interno y el suyo. Incluso si necesita poner una @Entitiyanotación del ORM en su objeto de dominio, diría que esto no establece una "mención" de la capa externa. Debido a que las anotaciones son solo metadatos, ningún código que no las busque específicamente las verá. Y lo más importante, nada necesita cambiar si los elimina o los reemplaza con una anotación de base de datos diferente.
Por el contrario, si cambias tu dominio e hiciste todos esos mapeadores, tienes que cambiar mucho.
Enmienda: Arriba está un poco simplificado e incluso podría estar equivocado. Porque hay una parte en la arquitectura limpia que quiere que crees una representación por capa. Pero eso tiene que verse en el contexto de la aplicación.
A saber, lo siguiente aquí https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
Lo importante es que las estructuras de datos simples y aisladas se pasan a través de los límites. No queremos engañar y pasar entidades o filas de bases de datos. No queremos que las estructuras de datos tengan ningún tipo de dependencia que viole la Regla de dependencia.
Pasar entidades desde el centro hacia las capas externas no viola la regla de dependencia, pero se mencionan. Pero esto tiene una razón en el contexto de la aplicación prevista. Pasar entidades alrededor movería la lógica de la aplicación hacia el exterior. Las capas externas necesitarían saber cómo interpretar los objetos internos, efectivamente tendrían que hacer lo que se supone que deben hacer las capas internas como la capa de "caso de uso".
Además de eso, también desacopla las capas para que los cambios en el núcleo no requieran necesariamente cambios en las capas externas (vea el comentario de SteveCallender). En ese contexto, es fácil ver cómo los objetos deben representar específicamente el propósito para el que se usan. Además, las capas deben comunicarse entre sí en términos de objetos que están hechos específicamente para el propósito de esta comunicación. Esto puede incluso significar que hay 3 representaciones, 1 en cada capa, 1 para el transporte entre capas.
Y hay https://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Architecture.html que aborda arriba:
Otras personas se han preocupado de que el resultado neto de mi consejo sería una gran cantidad de código duplicado y muchas copias de memoria de una estructura de datos a otra a través de las capas del sistema. Ciertamente tampoco quiero esto; y nada de lo que he sugerido conduciría inevitablemente a la repetición de estructuras de datos y a una excesiva copia de campo.
Esa OMI implica que la copia simple de objetos 1: 1 es un olor en la arquitectura porque en realidad no estás usando las capas y / o abstracciones adecuadas.
Más tarde explica cómo imagina todas las "copias"
Separa la interfaz de usuario de las reglas de negocio al pasar estructuras de datos simples entre los dos. No deja que sus controladores sepan nada sobre las reglas comerciales. En cambio, los controladores desempaquetan el objeto HttpRequest en una estructura de datos simple y luego pasan esa estructura de datos a un objeto interactivo que implementa el caso de uso invocando objetos de negocios. El interactor luego reúne los datos de respuesta en otra estructura de datos vainilla y los devuelve a la IU. Las vistas no conocen los objetos comerciales. Simplemente miran esa estructura de datos y presentan la respuesta.
En esta aplicación, hay una gran diferencia entre las representaciones. Los datos que fluyen no son solo las entidades. Y esto garantiza y exige diferentes clases.
Sin embargo, se aplica a una aplicación simple de Android como un visor de fotos donde la Photoentidad tiene aproximadamente 0 reglas de negocio y el "caso de uso" que trata con ellas es casi inexistente y en realidad está más preocupado por el almacenamiento en caché y la descarga (ese proceso debería ser IMO representado más explícitamente), el punto de hacer representaciones separadas de una foto comienza a desaparecer. Incluso tengo la sensación de que la foto en sí misma es el objeto de transferencia de datos mientras falta la verdadera capa de núcleo de lógica de negocios.
Existe una diferencia entre "separar la interfaz de usuario de las reglas de negocio al pasar estructuras de datos simples entre los dos" y "cuando desee mostrar una foto, renómbrela 3 veces en el camino" .
Además de eso, el punto en el que veo que esas aplicaciones de demostración no representan la arquitectura limpia es que agregan un gran énfasis en la separación de capas en aras de la separación de capas, pero ocultan efectivamente lo que hace la aplicación. Eso contrasta con lo que se dice en https://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html , es decir, que
la arquitectura de una aplicación de software grita sobre los casos de uso de la aplicación
No veo ese énfasis en separar capas en la arquitectura limpia. Se trata de la dirección de dependencia y de centrarse en representar el núcleo de la aplicación (entidades y casos de uso) en Java de forma ideal sin dependencias hacia el exterior. No se trata tanto de dependencias hacia ese núcleo.
Entonces, si su aplicación realmente tiene un núcleo que representa las reglas de negocios y los casos de uso, y / o diferentes personas trabajan en diferentes capas, sepárelas de la manera prevista. Si, por el contrario, solo escribe una aplicación simple, no se exceda. 2 capas con límites fluidos pueden ser más que suficientes. Y las capas se pueden agregar más adelante también.
BankAccountpero con reglas específicas de la aplicación, qué puede hacer con esa cuenta.