Capa de aplicación vs capa de dominio?

Estoy leyendo Diseño impulsado por dominio de Evans y estoy en la parte discutiendo la arquitectura en capas. Me acabo de dar cuenta de que las capas de aplicación y dominio son diferentes y deben estar separadas. En el proyecto en el que estoy trabajando, están mezclados y no puedo notar la diferencia hasta que leo el libro (y no puedo decir que esté muy claro para mí ahora), realmente.

Mis preguntas, dado que ambas se refieren a la lógica de la aplicación y se supone que están limpias de aspectos técnicos y de presentación, ¿cuáles son las ventajas de trazar un límite entre estas dos?

Hace poco leí DDD yo mismo. Cuando llegué a esta sección, me sorprendió gratamente descubrir que descubrí la misma arquitectura de 4 capas que hizo Evans. Como señaló @lonelybug, la capa de dominio debe estar completamente aislada del resto del sistema. Sin embargo, algo tiene que traducir los valores específicos de la interfaz de usuario (cadenas de consulta, datos POST, sesión, etc.) en objetos de dominio. Aquí es donde entra en juego la capa de aplicación. Su trabajo es traducir de ida y vuelta entre la interfaz de usuario, la capa de datos y el dominio, ocultando efectivamente el dominio del resto del sistema.

Ahora veo muchas aplicaciones ASP.NET MVC donde casi toda la lógica está en los controladores. Este es un intento fallido de implementar la arquitectura clásica de 3 capas. Los controladores son difíciles de probar porque tienen muchas preocupaciones específicas de la interfaz de usuario. De hecho, escribir un controlador para que no esté directamente relacionado con los valores del "contexto HTTP" es un desafío serio en sí mismo. Idealmente, el controlador debe realizar solo la traducción, coordinar el trabajo y escupir la respuesta.

Incluso puede tener sentido hacer una validación básica en la capa de aplicación. Está bien que el dominio asuma que los valores que entran tienen sentido (es una identificación válida para este cliente y esta cadena representa una fecha / hora). Sin embargo, la validación que involucra lógica empresarial (¿puedo reservar un boleto de avión en el pasado?) Debe reservarse para la capa de dominio.

Martin Fowler en realidad comenta cuán planas son la mayoría de las capas de dominio en estos días . Aunque la mayoría de las personas ni siquiera saben qué es una capa de aplicación, descubre que muchas personas hacen objetos de dominio bastante tontos y capas de aplicación complejas que coordinan el trabajo de los diferentes objetos de dominio. Soy culpable de esto yo mismo. Lo importante no es construir una capa porque algún libro te lo dijo. La idea es identificar responsabilidades y separar nuestro código en función de esas responsabilidades. En mi caso, la "capa de aplicación" evolucionó de forma natural a medida que aumentaba las pruebas unitarias.

Tomando de los patrones de diseño empresarial de Martin Fowler, las capas más comunes son:

• Presentación: estas son vistas, plantillas de presentación que generan la interfaz de interacción para su aplicación (estoy usando la interacción en caso de que otros sistemas accedan a su aplicación a través de servicios web o RMI, por lo que puede no ser una interfaz de usuario). Esto también incluye controladores que deciden cómo se ejecutarán las acciones y cómo.

• Dominio: aquí es donde residen las reglas y la lógica de su negocio, sus modelos de dominio están definidos, etc.

• Fuente de datos: esta es la capa de mapeo de datos (ORM) y la fuente de datos (base de datos, sistema de archivos, etc.)

¿Cómo se dibujan los límites entre las tres capas?

• No ponga lógica de presentación específica dentro de sus modelos u objetos de dominio

• No coloque lógica dentro de sus páginas y controladores, es decir, lógica para guardar objetos en la base de datos, crear conexiones de base de datos, etc., lo que hará que su capa de presentación sea frágil y difícil de probar.

• Use un ORM que le permita desacoplar el acceso a la fuente de datos y las acciones del modelo

• Siga el paradigma del controlador delgado: modelo gordo, los controladores son para controlar el proceso de ejecución, no para llevarlo a cabo, más en http://www.littlehart.net/atthekeyboard/2007/04/27/fat-models-skinny-controllers/ y http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model modelo, vista y controlador,

La capa de dominio modela el negocio de su aplicación. Esta debería ser su interpretación clara de sus reglas, su dinámica de componentes y su estado en cualquier momento dado.

La capa de aplicación está "preocupada" por definir los trabajos necesarios para realizar una determinada tarea de aplicación. Principalmente, es responsable de ordenar el trabajo de dominio necesario e interactúa con otros servicios (externos o no).

Por ejemplo , mi aplicación de software financiero tiene una operación de usuario para cambiar el estado de una entidad modelo (entidad como se define en DDD [89]):

• "El jefe de operaciones puede aprobar una propuesta financiera".

Pero, como proceso de solicitud, además de todas las consecuencias del modelo de esta operación, tengo que enviar una comunicación interna a otros usuarios de la aplicación. Este tipo de trabajo está "orquestado" en la capa de aplicación. No quisiera que mi capa de dominio piense en dirigir un servicio de mensajería. (y ciertamente esto no es una responsabilidad de la capa de presentación). De cualquier manera, una cosa es segura: necesito una nueva capa, ya que mi capa de dominio se trata del negocio principal y mi capa de presentación se trata de interpretar los comandos del usuario y presentar los resultados.

Notas:

• Los negocios son una de esas palabras que con frecuencia conducen a múltiples interpretaciones de su significado, pero seguro que puede encontrar muchos ejemplos y comentarios en DDD;
• DDD significa libro de diseño impulsado por dominio de Eric Evans y número dentro de corchetes para el número de página.

La capa de dominio debe diseñarse como una capa de aislamiento, lo que significa que la lógica y las reglas del negocio no deben verse afectadas por cambios en los códigos (en la capa de aplicación, la capa de presentación y la capa de infraestructura).

Se supone que Application Layer debe estar diseñado para proporcionar algunas funciones sobre lo que puede hacer una interfaz de sistema (aplicación) (piense esto como una API o RESTful). Por ejemplo, los usuarios pueden iniciar sesión en un sistema, y ​​en esta acción de aplicación (inicio de sesión), los códigos de capa de aplicación serán los códigos de cliente para la Capa de dominio (o Capa de infraestructura), en la que se recupera el objeto de dominio de Usuario y se aplican los métodos de este objeto para implementar el función 'login'.

La capa de aplicación también debe diseñarse como una capa de aislamiento, lo que significa que los comportamientos de la aplicación no deben verse afectados por cambios en los códigos (en la capa de presentación, la capa de dominio y la capa de infraestructura).

El objetivo del modelado controlado por dominio es separar el modelo de dominio esencial y hacer que exista sin dependencias de otras capas y otros problemas de aplicación.

Esto le permite concentrarse en el dominio en sí mismo sin distracciones (como la coordinación entre la interfaz de usuario y los servicios de persistencia).

• La capa de aplicación y la capa de dominio están incluidas en el alcance de la implementación.
• La capa de aplicación actúa como API.
• La capa de dominio actúa como una implementación de API, contiene lógica de negocios, por lo que también se llama capa de lógica de negocios.

La razón principal de estos límites es la separación de las preocupaciones . El código que accede al almacén de datos solo debería preocuparse por acceder al almacén de datos. No debe ser responsable de hacer cumplir las reglas sobre los datos. Además, la interfaz de usuario debe ser responsable de actualizar los controles en la interfaz de usuario, obtener valores de la entrada del usuario y traducirlos a algo que la capa de dominio pueda usar, y nada más. Debe llamar a las operaciones proporcionadas por la capa de dominio para realizar las acciones necesarias (por ejemplo, guardar este archivo). Un servicio web que se llama debería ser responsable de convertir del medio de transmisión a algo que la capa de dominio pueda usar, y luego llamar a la capa de dominio (la mayoría de las herramientas hacen mucho de este trabajo por usted).

Esta separación, cuando se implementa adecuadamente, puede brindarle la capacidad de cambiar partes de su código sin afectar a otras. Por ejemplo, tal vez el orden de clasificación de una colección devuelta de objetos debe cambiar. Como sabe que la capa responsable de la manipulación de datos (generalmente la capa de lógica de negocios) maneja estas cosas, puede identificar fácilmente dónde se debe cambiar el código. Además de no tener que modificar cómo se recupera del almacén de datos, o de cualquiera de las aplicaciones que usan el dominio (la interfaz de usuario y el servicio web de mi ejemplo anterior).

El objetivo final es hacer que su código sea lo más fácil de mantener posible.

Como nota al margen, algunas cosas no se pueden encasillar en una capa específica del dominio (por ejemplo, registro, validación y autorización). Estos elementos se conocen comúnmente como preocupaciones transversales, y en algunos casos se pueden tratar como una capa que se mantiene por sí misma y que todas las otras capas pueden ver y usar.

Personalmente, creo que el enfoque en capas está desactualizado y que el enfoque de servicio es mejor. Todavía tienes la línea clara dibujada en la arena sobre quién hace qué, pero no te obliga a ser tan jerárquico. Por ejemplo, un servicio de orden de compra, un servicio de facturación y un servicio de envío, desde la perspectiva de la aplicación, todos estos servicios representan su dominio, y el aplazamiento de responsabilidad que describí anteriormente todavía es válido en este contexto, simplemente se ha modificado. que su dominio existe en múltiples lugares, utilizando aún más el concepto de separación de preocupaciones.