Aunque la dio a conocer Robert C. Martin, fue propuesta por Ivar Jacobson en 1992. Su nombre original, Entity-Interface-Control, se cambió para evitar confusiones con conceptos similares de los lenguajes de programación. Es un patrón arquitectónico utilizado en el diseño de software orientado a objetos, en el que los casos de uso categorizan las clases que componen el software según su responsabilidad.
“La arquitectura de una aplicación se rige por sus casos de uso.”
Jacobson, proponía este modelo para el análisis y diseño de actividades, y su representación mediante sus estereotipos UML.
Su propósito, producir una arquitectura agnóstica a la implementación, que no esté atada a una plataforma, aplicación, lenguaje o marco específico; y cuyos elementos estén unidos por un acoplamiento lo más débil posible. Esta es su principal diferencia con MVC, ya que ni controladores ni entidades, conocen el medio por el que se está accediendo a ellas. En MVC, siempre hay una dependencia con el mecanismo de entrega.
Flujo boundary-controller-entity
Sus responsabilidades:
Entity
Las entidades contienen los datos utilizados por el sistema y los cálculos asociados a estos. Cada entidad representa un concepto relevante dentro del dominio del problema, y mantiene la identidad de los datos persistentes.
Adicionalmente, Jacobson propone que la naturaleza de la lógica de la entidad, es tal, que si la estructura de los datos que contiene cambia, las operaciones sobre estos datos también tendrán que cambiar. Por eso deben estar ubicados juntos.
Por lo tanto, al igual que defienden otros autores, esta recomendación va en contra de lo que actualmente se conoce como entidades anémicas modelo anémico.
Boundary (interfaz)
Se trata de los objetos que modelan todas las interacciones del sistema con los actores externos. Cualquier interacción del sistema con un actor, debe pasar por un objeto Boundary. Ya sea la implementación de la funcionalidad para el procesamiento de datos para una interfaz grafica de usuario o de un API web. Por lo tanto su naturaleza es funcional, aceptan solicitudes y producen respuestas como ressultado.
Controlador
La relevancia de este último tipo de objeto es proporcionar la comunicación entre interfaces y entidades, evitando que éstas últimas propaguen su lógica a los actores externos con los que se comunican.
Los controladores, según Jacobson son aquellos que orquestan un caso de uso, así como los objetos que contengan un comportamiento relevante para éste y que no sean una entidad o una interfaz. Aceptan peticiones de o límites, deciden qué hacer con ellas y manipulan el estado de la aplicación. Por tanto conocen los modelos de petición y respuesta, DTO’s. De alguna manera son la implementación concreta de los límites.
Interacciones
En cuanto a las interacciones que se pueden dar entre los tres tipos de objetos, deben ser tales, que respeten la Ley de Demeter LoD, o principio del mínimo conocimiento. Se trata de una directriz de diseño para el desarrollo de software, especialmente de programas orientados a objetos. En su forma general, la LoD es un caso específico de acoplamiento débil.
- Cada unidad debe tener un conocimiento limitado sobre otras unidades: sólo se deben tratar con las unidades “estrechamente” relacionadas.
- Cada unidad debería hablar sólo con sus amigos; no hablar con extraños.
- Y sólo, con sus amigos inmediatos.
La noción fundamental es que un objeto determinado debe suponer lo menos posible sobre la estructura o las propiedades de cualquier otra cosa (incluidos sus subcomponentes), de acuerdo con el principio de “ocultación de información”. Puede considerarse como un corolario del principio de mínimo privilegio, que dicta que un módulo sólo posee la información y los recursos necesarios para su propósito legítimo
Reglas
Así pues, de acuerdo a LoD, y los elementos que componene este patrón de arquitectura, las interacciones que se pueden dar entre ellos son:
- Cada caso de uso se representa por una clase de control
- Cada relación entre el caso de uso y un actor, se representa por una clase Boundary
- Los actores solo conocen y se comunican con boundaries.
- Las boundaries deben comunicarse exclusivamente con actores y clases de control
- Los controladores se comunican con boundaries y entidades, y si lo requiriesen con otros controladores
- Las entidades, pueden comunicarse con otras entidades o controladores.
Referencias
