¿Funcionan realmente bien DDD y SOA?

Question

Por favor, hágamelo saber, muy suavemente, si estoy totalmente destruyendo el concepto de DDD, pero este es mi dilema.

Digamos que tengo el siguiente modelo de dominio:

Teacher 
    IList<Class> 

Class 
    Teacher 
    IList<Student> 

Student 
    Class 

Ahora bien, desde una perspectiva DDD, parece que el Maestro es mi raíz, y de hecho, en una aplicación sencilla, que podría llevar alrededor de mi Maestro con sus clases y estudiantes y actuar según sea necesario. Pero en una situación SOA, digamos que he derribado a mi profesor, sus clases y estudiantes con fines de visualización (como dtos), y ella quiere agregar un estudiante. Seguramente no voy a enviar todo el gráfico objeto al servidor y recuperar los objetos de dominio de la base de datos solo para poder agregar un nuevo estudiante, ¿verdad?

¿Dónde está el punto ideal aquí, o me falta totalmente el barco?

Gracias!

Late Upate: Tal vez estoy respondiendo mi propia pregunta, pero supongo que un enfoque es hacer que mi servicio de maestro tenga varios métodos de administración de estudiantes (AddStudent, UpdateStudent) para que mi raíz administre todo en lugar de tener un solo servicio por objeto

Answer 1

Estás pensando en el rendimiento, pero te sorprenderá. En mis servicios web SOA utilizo gráficos de objetos completos y el rendimiento está dentro de los límites aceptables. Sugeriría usar objetos comerciales y métodos web empresariales como SaveTeacher(Teacher t) a menos que sea absolutamente necesario utilizar DTO por motivos de rendimiento y métodos web CRUD asociados como AddStudent(long teacherId, Student student)
Pero incluso si usa el último puede aplicar el concepto DDD cargando el profesor de su persistencia almacene el docente, adjunte al estudiante y guarde al maestro de nuevo en la tienda de persistencia.

Answer 2

Para SOA, necesita Application Services. Eche un vistazo al here para descubrir dónde debe ir su funcionalidad.

Answer 3

Yo diría que ambos están perdiendo el barco, y al mismo tiempo en el camino correcto ... déjenme explicar.

DDD es la mejor manera que conocemos como industria para codificar la realidad de un problema comercial en un dominio de solución que podemos asignar a un programa de computadora. DDD es una metodología para abstraer un dominio real en algo más manejable y relevante para nosotros, estas son cosas buenas.

El problema al que se enfrenta es en la implementación, la elección predominante de implementación durante los últimos 20-30 años ha sido la orientación a objetos (OO), el mecanismo central de pasar objetos en OO es pasando referencias a objetos en el el mismo espacio de memoria que tu. Entonces, los problemas que enfrentas en los gráficos de objetos grandes nunca son un problema real.

Introduzca la orientación del servicio (SO), que cambia las cosas, ya no está pasando referencias a objetos, sino intercambiando mensajes entre servicios. El tamaño del mensaje ahora se convierte en una preocupación.

Si aceptamos que el paradigma de implementación ha cambiado, debemos aceptar que algunos de nuestros mejores patrones/prácticas de OO ya no se aplican o no necesitan revisión.

Si desea entrar en la forma de pensar SO, tiene que, creo (mi opinión aquí), dejar pasar la idea de un dominio rico ligeramente. Yo llamo a este nuevo concepto un Dominio orientado a servicios (SO-Domain).

En un SO-Domain, el estado del dominio y el comportamiento del dominio se divide entre los mensajes que pasa y los servicios que utiliza.

Entonces el estado o los atributos del profesor son parte del TeacherDTO, pero el comportamiento es parte del servicio del maestro.

En términos OO, este es un dominio anémico, pero en un sentido TAN no es tan malo ya que esto le da una flexibilidad increíble, ya que no tiene una gran cosa, el estado puede usarse en múltiples contextos .

Aún tiene un dominio válido, solo tiene particiones diferenciales, los mensajes mantienen el estado y mantienen el comportamiento de los servicios.

El resto se reduce al diseño de la interfaz de servicio, por lo que para obtener la clase de un profesor puede tener cosas como List RetrieveTeacherClasses (teacherIdentifier). Para agregar un alumno AddStudentToClass (Student, classId).

Hay un millón de formas diferentes de hacer esto, encontrará la que le funcione, pero como regla general, debe seguir un paradigma consciente del estado, esto significa que el mensaje enviará cualquier estado que necesite el servicio. consciente, esto permite que el servicio sea sin estado, y el servicio sin estado significa escalabilidad.

Pratik menciona el rendimiento, las verdaderas ganancias de rendimiento en una escala de todo el sistema no se logran alterando el tamaño de los gráficos de objeto, sino la capacidad de cada servicio en la solución para escalar independientemente.

Éstos son algunos enlaces a más de estas ideas

Building a SOA

SOA Design Pattern

Achieving integrity in a SOA

Why your SOA should be like a VW Beetle

SOA explained for your boss

WCF Service Performance

Answer 4

Lo que está diciendo es Vijay añadir un TeacherService con un método AddStudent

interface ITeacherService 
{ 
    Teacher GetTeacher (name teacher); 
    void AddStudent (Teacher teacher, Student student); 
} 

Así se obtendría con algo como lo siguiente:

Student student = new Student ("Bobby Drop Tables;"); 
Teacher teacher = teacherService.GetTeacher ("Bob"); 
teacherService.AddStudent (teacher, student);