Implementación del diseño impulsado por el dominio

Question

¿Alguien está usando las técnicas de Domain Driven Design? Recientemente leí el libro de Eric Evans del mismo nombre (bueno, la mayor parte) y estaría interesado en saber de alguien que ha implementado todo/parte de él en un proyecto (particularmente en C#/C++)

He mantenido esta pregunta abierta porque me gustaría ver todos los comentarios posibles, pero tengo algunas preguntas en particular:

1 - ¿Deberían los tipos de valor ser verdaderos 'tipos de valor' si el lenguaje lo admite? ? p.ej. una estructura en C#

2- ¿Hay alguna función en C# que hace más clara la asociación entre la lengua y el modelo (por ejemplo, esto es una entidad, esto es un agregado etc.)

Answer 1

Sí! Utilizo DDD en mis proyectos (¡pero I'm biased!)

Recuerde que el Diseño Dirigido por Dominio proporciona pautas, respuestas no estrictas. Solo después de experimentar comprenderá qué aspectos funcionan para su proyecto específico.

en su pregunta:

1 - Usted podría utilizar estructuras - pero puede haber limitaciones técnicas que le impedirá utilizar ellos. Por ejemplo, puede tener entidades que hagan referencia a miles de objetos de valor que tengan los mismos valores. En este caso, podría ser mejor usar un objeto flyweight para mantener el uso de la memoria .

2 - Sugeriría usar interfaces (por ej.IEntity, IValueObject, IAggregateRoot, ISpecification). Los genéricos y LINQ pueden ayudar a resolver los problemas técnicos, pero son menos útiles desde la perspectiva del diseño .

He creado una [libre biblioteca .NET] [2] centrada específicamente en DDD, que podría encontrar ideas/inspiración de. [Para saber más sobre él aquí.] [3] (proyecto está muerto)

estoy realmente interesado sin embargo: qué aspectos de DDD crees que va a beneficiar a usted? Los aspectos "Impulsados ​​por el dominio" o los aspectos de implementación?

Answer 2

1: depende . Los tipos de valores en C# son para pimitives atómicos (int, byte, etc.). Si tienes algo así, tiene sentido. Si su tipo de valor es más grande, no.

2: No. En general, esta no es una función de idioma.

Sugiero que en la próxima lectura: "Aplicaciones de objetos de construcción que funcionan" de Scott Ambler.

Answer 3

1 - ¿Deberían los tipos de valor ser verdaderos 'tipos de valor' si el lenguaje lo admite?

Creo que la respuesta dependerá del uso y otros factores dentro de su aplicación, pero el patrón que probablemente esté buscando es "Data Transfer Object" que tiene propiedades, getters y setters, pero nada más . Puede ser una estructura o un objeto, y los objetos probablemente simplificarán los problemas de administración de memoria, especialmente con respecto al boxeo.

2- ¿Hay alguna característica de C# que hace más clara la relación entre la lengua y el modelo (por ejemplo, se trata de una entidad, esto es un agregado, etc.)

me gustaría ir con convenciones de nombres, por ejemplo, "CustomerEntity", "OrderAggregate", etc.

Buena pregunta; Estoy esperando ver respuestas.

Answer 4

1 - ¿Deberían los tipos de valor ser verdaderos 'tipos de valor' si el lenguaje lo admite? p.ej. una estructura en C#

No se confundan entre la noción DDD de "Value Object" y la noción CLR de "Value Type" (estructuras en C#). El primero tiene que ver con el diseño, y el segundo es una consideración de implementación de bajo nivel que realmente tiene más que ver con la administración de la memoria que cualquier otra cosa.

2 - ¿Hay alguna característica de C# que hace más clara la relación entre la lengua y el modelo (por ejemplo, se trata de una entidad, se trata de un agregado, etc.)

Al abordar entidades vs. valores, sí Hemos encontrado que usar readonly en C# es muy útil para implementar Value Objects en DDD. Estamos adoptando DDD a lo grande en Pluralsight, y blogueo sobre esto de vez en cuando en el blog Pluralsight. De hecho, he programado dos entradas de blog sobre readonly y DDD para salir a finales de esta semana.

[1] http://blog.pluralsight.com/tag/ddd/