DDD: ¿cómo deben organizarse las capas?
Soy muy nuevo en el desarrollo de software. Personalmente creo que la arquitectura por capas es una gran manera de reducir las complejidades que surgen en el proceso de desarrollo de software en un enfoque orientado a objetos y, por no mencionar, para mantener su código organizado. Ahora, me he encontrado con algunos problemas que se introducirán con DDD (Domain Driven Design). Por supuesto, los de nivel principiante.
Aquí está -
Digamos que quiero construir una aplicación para guardar los datos relacionados con la "persona" en la base de datos y mostrar detalles de la persona en una red de datos wpf (DDD definitivamente no es para las aplicaciones de tal escala, sino solo para mantener las cosas simples para un aficionado como yo). Por lo tanto, diseñé una clase de dominio "Persona", algo así como -
public class Person
{
public Person(dataType paramA, dataType paramB)
{
_fieldA = paramA;
_fieldB = paramB;
}
private dataType _fieldA;
public dataType PropertyA
{
//encapsulates _fieldA
}
private dataType _fieldB;
public dataType PropertyB
{
//encapsulates _fieldB
}
public dataType PropertyX
{
//some code based on private fields
}
public dataType PropertyY
{
//some code based on private fields
}
private dataType MethodPQR(dataType param)
{
//some code
}
public dataType MethodUVW(dataType paramOne, dataType paramTwo)
{
//some code
}
}
Ahora, mi comprensión de DDD dice que la arquitectura (la versión más simple de la misma) debe ser la siguiente (por favor, corríjame si me equivoco) –
Nota:
Quiero que la cuadrícula de datos esté vinculada a alguna recopilación observable, solo para reflejar cualquier tipo de cambio inmediatamente.
-
Es una aplicación wpf pero no necesariamente estar en el patrón MVVM y deliberadamente quiero usar el código detrás (no tengo idea si el código detrás de sí mismo representa la Capa de aplicación)
Así que mis preguntas son -
¿Qué tipo de códigos deben pertenecer a la Capa de aplicación?
Mi conjetura es, definitivamente no debería enlazar un ObservableColletion de mi objeto del dominio (Persona) como el itmsSource del datagrid. ¿Qué tipo de objeto debo extraer del objeto de dominio y cómo?
Para mantener un desacoplamiento entre los objetos de la Capa de presentación y el objeto de la Capa de dominio puede haber una convención como
“never instantiate domain objects directly in presentation layer”. ¿Cuáles son los enfoques no"directos" entonces?Si el Código detrás de las conversaciones a la Capa de aplicación entonces debe la Capa de Aplicación hablar con el Repositorio? Pero, ¿qué pasa si se necesita algún tipo de acceso al dominio que sea no relacionado con el acceso a datos (puede que no esté en esta aplicación, pero puede ocurrir, ¿verdad?) ¿Quién es ese tipo X en la Capa de dominio con el que la Capa de Aplicación debería hablar?
Sé que todas mis preguntas y problemas son de nivel amateur. Pero son preguntas y problemas. Por lo tanto, si alguien tiene tiempo, cualquier respuesta será apreciada.
EDIT: No estoy seguro de si el Repositorio de Datos debería tener una referencia del Modelo de Dominio.
1 answers
Hablando en términos de DDD más "clásico", los objetos de dominio sí normalmente no se permiten en ningún lugar fuera del dominio. Pero no es una regla absoluta que los objetos de dominio no se utilicen en la capa de presentación. Por ejemplo, Naked Objects representa una escuela de pensamiento donde los objetos de dominio se usan directamente. Yo mismo me adhiero sobre todo a una filosofía donde los objetos de dominio no se utilizan directamente, por lo que no estoy familiarizado con todas las prácticas que sugieren, yo personalmente pensaría vinculante a un objeto de dominio directamente sería mal aconsejado, pero ... Solo tenga en cuenta que no todo el mundo ve esto como un requisito.
Si no permite objetos de dominio fuera del propio dominio, normalmente utilizará Objetos DTO o de transferencia de datos que son clases de propiedad simple que no tienen comportamientos de dominio. Los DTO a menudo reflejan exactamente la estructura del modelo de dominio, pero no tienen que hacerlo.
La lógica de negocio se supone que debe implementarse en el modelo de dominio, tanto de lo que la capa de aplicación está involucrada en la coordinación de varios servicios, normalmente para llevar los datos hacia y desde las aplicaciones cliente. Muchas personas utilizan alguna forma de SOA o al menos servicios web para esto. Estos llaman a los repositorios, pero también requieren que otros componentes como ensambladores tomen los objetos de dominio devueltos por las llamadas al repositorio y copien los valores de propiedad en DTOs, que luego son serializables y devueltos al llamante. La persona que llama es a menudo un presentador o controlador, pero si no están utilizando MVC o MVP el llamante todavía estaría en la capa de presentación. El viaje inverso es más complejo: la interfaz de usuario puede devolver DTO que representan actualizaciones o DTO que representan nuevos objetos para agregar. Mediar estas actividades de ida y vuelta es principalmente el propósito de la capa de aplicación.
En cuanto al "acceso sin datos" de la capa de dominio, hay un par de ejemplos típicos. La mayoría de las personas generalmente se refieren al componente" X " en el que puede estar pensando como un Servicio de Dominio. Un servicio de dominio difiere de un Servicio de aplicación por su proximidad al modelo de dominio y la presencia de una lógica de negocio real.
Por ejemplo, si una aplicación implica algún tipo de colocación de pedidos, en realidad hay dos preocupaciones: colocación de pedidos y cumplimiento de pedidos. Los servicios de aplicaciones median la transferencia de los datos necesarios para formular una colocación de pedidos a la interfaz de usuario y luego devuelven el pedido que el usuario desea realizar. Pero eso solo es mediar la transferencia de datos y ahí es donde terminan los Servicios de Aplicaciones. Un Servicio de dominio puede entonces ser necesario para aplicar reglas de negocio y construir objetos de dominio adicionales que son necesarios para cumplir realmente ese orden.
En general me parece que es un concepto útil o metáfora que se puede aplicar a muchos escenarios - un Servicio de Aplicación facilita una solicitud de algún tipo, en términos de la solicitud envío solamente . Un Servicio de Dominio por otro lado facilita la solicitud real cumplimiento.
El único otro modo de "acceso" que no sea orientado a datos que he encontrado o puedo imaginar fácilmente es la funcionalidad orientada a procesos. Esto no se encuentra en todas las aplicaciones, pero es frecuente en ciertos campos. Por ejemplo, en el área de salud donde trabajo, es posible que desee aplicaciones que incorporen elementos significativos de gestión tanto de los datos clínicos como del proceso clínico. Resuelvo este problema al no hacer que el énfasis en el proceso sea parte de mi modelo de dominio y el uso de diferentes herramientas para que en su lugar.
Las técnicas de OOP no son adecuadas para un proceso real en sí, son útiles para proporcionar datos y capturar datos de un proceso. Orientado a objetos es, después de todo, también orientado principalmente a sustantivos. Para la gestión de procesos en tiempo real necesita " programación orientada a verbos "más que"programación orientada a sustantivos". Las herramientas de flujo de trabajo son herramientas "orientadas a verbos" que pueden ser complementarias a los modelos impulsados por dominios para aplicaciones que son tanto los datos intensivos como los procesos intensivos. Hago mucho trabajo que involucra tanto modelos DDD de C# como modelos de Base de flujo de trabajo, pero nuevamente esto solo es necesario para ciertos tipos de aplicaciones. Muchas aplicaciones empresariales típicas solo requieren modelos y servicios de dominio.
Finalmente, el aspecto más importante del DDD no es ninguna técnica o arquitectura. El verdadero corazón de la misma gira en torno al Lenguaje Ubicuo y la interacción con (en mi fuerte opinión La interacción directa con) expertos en dominios para destilar el conocimiento crítico del dominio. (La mayoría de las empresas que dicen hacer DDD en mi opinión no lo hacen porque muchas empresas se niegan a permitir que el negocio y el desarrollo interactúen directamente, pero ese es otro tema... ) Son las extracciones y la incorporación del conocimiento del dominio, más que cualquier técnica que realmente separa el DDD del OOP convencional y es ahí donde surge el valor real del DDD.
EDITAR
En cuanto al uso del repositorio, el diagrama es correcto. Normalmente, la capa de aplicación siempre pasa por un repositorio para objetos de dominio. En primer lugar, debe ser capaz de traer datos a la aplicación, y la mayoría de las aplicaciones también necesitan algún nivel de capacidad de consulta.
La capa de dominio OTOH normalmente hace no interactuar con los repositorios. Por lo general, desea que el modelo de dominio sea autónomo y desacoplado de cualquier tecnología específica, es decir, debe representar "conocimiento puro del dominio". La persistencia es inherentemente estrechamente acoplado a algún tipo de tecnología específica, por lo que en general las personas se esfuerzan por hacer que sus modelos de dominio estén libres de cualquier implementación de persistencia. Tiene repositorios, pero normalmente no desea llamar a métodos de repositorio en el modelo de dominio.
Dentro del propio modelo de dominio, los objetos se obtienen como objetos nuevos (que pueden ser instanciados directamente o a través de una fábrica) o bien se alcanzan mediante asociaciones transversales. A veces, al crear un nuevo objeto es no es práctico pasar todo lo necesario a un constructor, por lo que este es un caso en el que podría necesitar algún tipo de acceso a datos dentro del modelo de dominio en sí. Por lo general, lo que hacen las personas es pasar un servicio de datos a través de una interfaz para que el modelo de dominio pueda tener acceso a los datos, pero permanezca desacoplado de la implementación de la capa de datos. Pero en su mayor parte los objetos de dominio actúan e interactúan con otros objetos de dominio que ya están instanciados.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-05-08 10:50:09