Antes de añadir mi respuesta, debo calificarla. La Programación Orientada a Servicios se basa en los Principios OOP y el uso de OO Languages. Además, las SOA siguen la Inversión de Control y los Principios SÓLIDOS en los dientes. Así que muchos programadores orientados al servicio seguramente están llegando aquí. Entonces, esta respuesta es para los programadores orientados al servicio que llegan a esta pregunta, porque SOA se basa en OOP. Esto no responde directamente el ejemplo del PO, pero responde la pregunta desde una Perspectiva SOA.
En general, la Ley de Demeter no se aplica a Arquitecturas Orientadas a Servicios. Para OO, la Ley de Demeter está hablando de "objetos ricos" en OOP que tienen propiedades y métodos, y cuyas propiedades también pueden tener métodos. Con OOP Rich Models, es posible acceder a través de una cadena de objetos y métodos de acceso, propiedades, métodos de propiedades, métodos de propiedades, etc. Pero en Programación Orientada a Servicios, los Datos (Propiedades) están separados del Proceso (Métodos)) Sus Modelos (principalmente) solo tienen propiedades (Ciertamente nunca dependencias), y sus Servicios solo tienen Métodos y dependencias en otros Servicios.
En SOP, puede revisar libremente las propiedades de un modelo y las propiedades de sus propiedades. Nunca podrá acceder a métodos que no debería, solo un árbol de datos. Pero, ¿qué pasa con los Servicios? ¿La Ley de Demeter se aplica allí?
Sí, la Ley de Demeter puede ser aplicada a los servicios de SOP. Pero, nuevamente, la ley fue originalmente diseñada para modelos ricos en OOP. Y aunque la ley puede ser aplicada a los Servicios, la Inyección de Dependencia adecuada cumple automágicamente la Ley de Demeter. En ese sentido, DI no podría violar la ley.
En oposición limitada a Mark Roddy, no puedo encontrar ninguna situación en la que legítimamente se puede hablar de Dependency Injection y "consumidores" en la misma oración. Si por "consumidores" te refieres a una clase que está consumiendo otra clase, eso no tiene sentido.Con DI, tendría una raíz de composición que componga su gráfico de objetos, y una clase nunca debería saber que existe otra clase. Si por "consumidores" te refieres a un programador, entonces ¿cómo se forzarían a no a "hacer la inyección"? El programador es el que tiene que crear la raíz de composición, por lo que debe hacer la inyección. Un programador nunca debe "hacer la inyección" como una instanciación dentro de una clase para consumir otra clase.
Por favor revise el siguiente ejemplo que muestra soluciones reales separadas, sus referencias, y el código de aplicación:
En la parte superior derecha, tenemos el "Core". Muchos paquetes en NuGet y NPM tienen un proyecto "Core" que tiene Model, Interfaces y posiblemente incluso implementaciones predeterminadas. El Núcleo nunca debería depender nunca de algo externo.
En la esquina superior izquierda, tenemos una implementación externa del Core. La implementación depende del Núcleo, y también lo tiene conocimiento.
En la esquina inferior izquierda, tenemos un dominio independiente. El Dominio tiene una Dependencia en alguna Implementación del Núcleo, pero No necesita saber sobre la implementación.
Aquí es donde señalo que ni el Dominio ni la Implementación se conocen. Hay un 0% de posibilidades de que cualquiera llegue a (o más allá) del otro, porque ni siquiera saben que existen. El dominio solo sabe que hay un contrato, y de alguna manera puede consumir los métodos por lo que sea que se inyecte en él.
En la esquina inferior izquierda está la raíz de composición o el punto de entrada. Esto también se conoce como el "límite frontal" de la aplicación. La raíz de una aplicación conoce todos sus componentes y hace poco más que tomar entrada, determinar a quién llamar, componer objetos y devolver resultados. En otras palabras, solo puede decirle al dominio "Aquí, usa esto para cumplir tu contrato de ICalculateThings, luego dame el resultado de CalculateTwoThings.
De hecho, hay una manera de destruir todo en el mismo proyecto, hacer instancias concretas de Servicios, haga que sus dependencias sean propiedades públicas en lugar de campos privados, STILL Do Dependency-Injection (horriblemente), y luego haga que los servicios llamen a dependencias de dependencias. Pero eso sería malo, m'kay. Debería intentarlo Sería malo hacer eso.
Nota al margen, lo sobre-compliqué a propósito. Estos proyectos podrían existir en una sola solución (siempre y cuando el Arquitecto controle la Arquitectura de Referencia), y podría haber algunas simplificaciones más. Pero la separación en la imagen realmente muestra ho Poco conocimiento tiene el sistema sobre sus partes. Solo la raíz de composición (punto de entrada, límite frontal) necesita conocer las partes.
Conclusión (TL; DR;): En Oldskewl OOP, los modelos son ricos, y la Ley de Demeter se puede romper fácilmente buscando modelos de modelos para acceder a sus métodos. Pero en Newskewl SOP (construido sobre Principios e idiomas de OOP), los datos se separan del proceso. Así que puede sentirse libre de examinar las propiedades de los modelos. Luego, para los Servicios, las dependencias son siempre privadas, y nada sabe que exista algo más aparte de lo que les dicen las abstracciones, los contratos, las interfaces.
¿Puedes publicar un código de ejemplo? Si estás haciendo foo.bar(). Baz() entonces sí, estás rompiendo la Ley de Demeter. ¿Estás diciendo que terminas haciendo esto? – asterite