domain-driven-design - quickly - implementing domain driven design español

DDD: ¿Cómo se deben organizar las capas?

Question

Soy muy nuevo en el desarrollo de software. Personalmente, creo que la arquitectura en capas es una excelente 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 para ser introducido con DDD (Domain Driven Design). Por supuesto, los de nivel principiante.
Aquí está -
Digamos, quiero crear una aplicación para guardar datos relacionados con "personas" en la base de datos y mostrar detalles personales en un wpf datagrid (DDD definitivamente no es para las aplicaciones de tal escala, sino para simplificar las cosas para un aficionado como yo) . Entonces, 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) debería ser la siguiente (por favor, corríjame si me equivoco):

Nota:

1. Quiero que el datagrid esté vinculado a alguna ObservableCollection, solo para reflejar cualquier tipo de cambios al instante.

2. Es una aplicación wpf, pero no necesariamente para estar en el patrón MVVM y quiero usar el código detrás de forma deliberada (no tengo idea si el código detrás de sí mismo representa la capa de aplicación)

Así que mis preguntas son ...

1. ¿Qué tipo de códigos deben pertenecer a la capa de aplicación?

2. Mi conjetura es que, definitivamente, no debería enlazar un objeto ObservableColletion de mi objeto de dominio (Persona) como la fuente itms del datagrid. ¿Qué tipo de objeto debo extraer del objeto de dominio y cómo?

3. 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?

4. Si el código subyacente habla con la capa de aplicación, ¿debería la capa de aplicación hablar con el repositorio? Pero, ¿qué sucede si se necesita algún tipo de acceso a dominio que no esté 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 debe hablar la capa de aplicación?

Sé que todas mis preguntas y problemas son de un nivel muy amateur. Pero son preguntas y problemas por cierto. Entonces, si alguien tiene tiempo, cualquier respuesta será apreciada.

EDITAR: No estoy seguro de si el repositorio de datos debería tener una referencia del modelo de dominio.

Answer 1

Hablando en términos de DDD más "clásico", sí, los objetos de dominio normalmente no están permitidos 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, los objetos desnudos representan una escuela de pensamiento donde los objetos de dominio se usan directamente. Yo mismo me adhiero principalmente a una filosofía en la que los objetos de dominio no se usan directamente, por lo que no estoy familiarizado con todas las prácticas que sugieren, personalmente creo que la unión a un objeto de dominio directamente no sería aconsejable, pero ... Solo tenga en cuenta No todo el mundo ve esto como un requisito.

Si no permite objetos de dominio fuera del propio dominio, normalmente usaría DTO o Objetos de transferencia de datos, que son clases de propiedad simple y que no tienen comportamientos de dominio. Los DTO a menudo reflejan exactamente la estructura del modelo de dominio pero no tienen que hacerlo.

Se supone que la lógica de negocios debe implementarse en el modelo de dominio, por lo que gran parte de lo que está en la capa de aplicación está involucrado en la coordinación de varios servicios, generalmente para llevar los datos hacia y desde las aplicaciones cliente. Muchas personas usan algún tipo de SOA o al menos servicios web para esto. Estos invocan a los repositorios, pero también requieren que otros componentes, como los ensambladores, tomen los objetos de dominio devueltos de las llamadas al repositorio y copien los valores de propiedad en DTO, que luego pueden ser serializados y devueltos al llamante. La persona que llama a menudo es un presentador o controlador, pero si no está utilizando MVC o MVP, la persona que llama todavía estará en la capa de presentación. El viaje inverso es más complejo: la interfaz de usuario puede enviar 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" que puede estar considerando 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 lógica de negocios real.

Por ejemplo, si una solicitud involucra algún tipo de colocación de orden, en realidad hay dos preocupaciones: la colocación de orden y el cumplimiento de orden. Los Servicios de Aplicación median la transferencia de los datos necesarios para formular un pedido de pedido a la UI y luego devuelven el pedido que el usuario desea colocar. Pero eso es solo mediar la transferencia de datos y ahí es donde terminan los servicios de aplicación. Entonces puede ser necesario un Servicio de Dominio para aplicar reglas de negocios y construir objetos de dominio adicionales que sean necesarios para cumplir con ese orden.

En general, considero que es un concepto o metáfora útil que se puede aplicar a muchos escenarios: un Servicio de aplicación facilita una solicitud de algún tipo, en términos de la presentación de solicitudes únicamente. Un servicio de dominio, por otro lado, facilita el cumplimiento real de la solicitud.

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 prevalece en ciertos campos. Por ejemplo, en el campo de la salud donde trabajo, es posible que desee aplicaciones que incorporen elementos significativos de la gestión de los datos clínicos y del proceso clínico. Resuelvo este problema al no hacer que el énfasis del proceso sea parte de mi modelo de dominio y, en cambio, usar diferentes herramientas para eso.

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 los nombres. Para la gestión de procesos en tiempo real, se necesita "programación orientada al verbo" más que "programación orientada al nombre". Las herramientas de flujo de trabajo son herramientas "orientadas al verbo" que pueden ser complementarias a los modelos controlados por dominio para aplicaciones que requieren tanto datos como procesos. Hago mucho trabajo que involucra tanto modelos C # DDD como modelos de Workflow Foundation, pero nuevamente solo es necesario para ciertos tipos de aplicaciones. Muchas aplicaciones empresariales típicas solo requieren servicios y modelos de dominio.

Finalmente, el aspecto más importante de DDD no es ninguna técnica o arquitectura. Su verdadero corazón gira en torno al Lenguaje Ubicuo y la interacción con (en mi opinión fuerte la interacción DIRECTA con) los expertos en dominios para extraer el conocimiento de dominio crítico. (La mayoría de las compañías que dicen hacer DDD en mi opinión no lo hacen porque muchas compañías se niegan a permitir que el negocio y el desarrollo interactúen directamente, pero ese es otro tema ...) Es la extracción e incorporación de conocimiento del dominio, en lugar de cualquier otro. técnica que realmente separa DDD de OOP convencional y ahí es donde surge el valor real de DDD.

EDITAR

En cuanto al uso del repositorio, el diagrama es correcto. Normalmente, la capa de aplicación siempre pasa por un repositorio de objetos de dominio. En primer lugar, debe poder llevar datos a la aplicación, y la mayoría de las aplicaciones también necesitan cierto nivel de capacidad de consulta.

La capa de dominio OTOH generalmente no interactúa con los repositorios. Normalmente, desea que el modelo de dominio sea autónomo y desacoplado de cualquier tecnología específica, es decir, debe representar "conocimiento de dominio puro". La persistencia está inherentemente unida 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, por lo general, no desea llamar a los métodos de repositorio en el modelo de dominio.

Dentro del propio modelo de dominio, los objetos se obtienen como nuevos objetos (que pueden ser instanciados directamente oa través de una fábrica) o bien se pueden alcanzar mediante asociaciones de desplazamiento. A veces, al crear un nuevo objeto, 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 los datos dentro del propio modelo de dominio. Por lo general, lo que las personas hacen es pasar un servicio de datos a través de una interfaz para que el modelo de dominio pueda recibir 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.