Esto no responde exactamente a su pregunta, pero veo lo opuesto al diseño impulsado por el dominio como el diseño basado en bases de datos. En el diseño basado en bases de datos, primero se crea el esquema de la base de datos y luego se crean las clases con pleno conocimiento de cómo se ve el esquema. La ventaja es que tiene una mejor comprensión de lo que está sucediendo bajo el capó y minimiza los efectos del desajuste de la impedancia. Sin embargo, la desventaja es que el esquema de la base de datos, debido a que es relacional en lugar de orientado a objetos, no se traduce a los objetos (por ejemplo, no existe el concepto de una colección en las bases de datos relacionales).
En el diseño impulsado por dominio, en teoría crea sus objetos de datos como lo haría con cualquier otra clase, y trata la base de datos simplemente como una capa de persistencia. En términos de Layman, la base de datos es solo un contenedor de almacenamiento y no le importa cómo se almacenan los objetos, solo que están almacenados de alguna manera. Esto elimina la falta de coincidencia de impedancia y tiene una cosa menos de qué preocuparse. En la práctica, sin embargo, aún debe tener en cuenta cómo se almacenan los objetos, y puede haber problemas de rendimiento cuando el ORM que está utilizando trata de escupir una consulta SQL compleja.
Editar:
He aquí un ejemplo de lo Dominio impulsada por el diseño debe ser, en principio. Digamos que usted tiene una clase de persona, al igual que (en C#):
public class Person
{
public int Id { get; set; }
public string Name { get; set; }
public Address Address { get; set; }
public ICollection<Person> Relatives { get; set; }
public Company Employer { get; set; }
}
Ahora, en una base de datos relacional, esto probablemente va a traducir en 3 mesas, una mesa de persona, la tabla de direcciones, y la mesa de la empresa, con una montón de relaciones entre ellos. Sin embargo, esto es muy diferente de cómo el programador ve este objeto. El programador lo ve como una instancia de un objeto Persona con 4 parámetros, uno de los cuales es un ICollection. Esto no concuerda muy bien con la estructura de la tabla de la base de datos, por lo tanto, el "desajuste de impedancia", o en términos de Laymen, una diferencia en el diseño entre el modelo relacional y el modelo de objeto.
En el diseño de dominio impulsada, yo debería ser capaz de hacer esto:
Person person = new Person();
// set each property to something
Database.Save(person);
Ahora, el objeto persona es salva. Puedo recuperarlo, así:
Person databasePerson = Database.Get<Person>(idOfPerson);
y va a devolver mi objeto Person, al igual que cómo era antes de lo guardé. De esta manera, no estoy preocupado en absoluto por cómo lo está guardando la base de datos, o me preocupo por la falta de correspondencia de la impedancia. Simplemente lo guardo y lo recupero según sea necesario.
Esto es todo en teoría sin embargo. En la práctica, probablemente tendrá que especificar manualmente la 'asignación', o cómo las clases saben de qué tabla/columna se obtienen datos en la base de datos. Puede ser bastante complejo cuando tratas de mapear a tipos más complejos como diccionarios y otros ADT, y también cuando tratas de extraer datos de múltiples tablas en una sola clase.
Por desgracia, es muy difícil de describir los beneficios de una respuesta corta. Si está escribiendo un sistema que contiene mucho comportamiento, en lugar de simplemente insertar/actualizar/eliminar, entonces puede beneficiarse al encapsular la lógica en un conjunto de clases (sus modelos de dominio). Es probable que no vea los beneficios hasta que tenga una solución lo suficientemente grande y su lógica de dominio sea lo suficientemente compleja. En ese caso, es muy agradable tener su lógica de dominio encapsulada en un solo lugar. –