Contenido

1. ¿Qué es el diseño impulsado por dominio? ....................................................................... 4

1.1. Los desafíos de crear software para dominios de problemas complejos ................ 4
1.1.1. Código creado sin un lenguaje común ................................................................... 5
1.1.2. A falta de organización ........................................................................................... 5
1.1.3. El patrón de bola de barro ahoga el desarrollo .................................................... 6
1.1.4. Falta de enfoque en el dominio del problema ....................................................... 7
1.2. Cómo las patronas de diseño con dominio gestionan la complejidad ..................... 7
1.2.1. Los patrones estratégicos de la DDD ................................................................. 7
1.2.2. Los patrones tácticos de DDD .......................................................................... 10
1.2.3. El espacio problemático y el espacio de solución ............................................ 11
1.3. Las prácticas y principios del diseño dirigido por dominio................................... 11
1.3.1. Centrándose en el dominio central .................................................................. 11
1.3.2. Aprendizaje a través de la colaboración ......................................................... 12
1.3.3. Creando modelos a través de la exploración y experimentación .................. 12
1.3.4. Comunicación .................................................................................................... 12
1.3.5. Entendiendo la aplicabilidad de un modelo .................................................... 13
1.3.6. En constante evolución del modelo .................................................................. 13
1.4. Errores en el diseño basado en el dominio .............................................................. 14
1.4.1. Los patrones tácticos son la clave para DDD .................................................. 14
1.4.2. DDD es un marco............................................................................................... 14
1.4.3. DDD es una bala de plata ................................................................................. 15
1.5. The Salient Points ...................................................................................................... 15
2. Destilar el dominio del problema ..................................................................................... 16
2.1. Conocimiento y colaboración ................................................................................... 16
2.1.1. Alcanzar un entendimiento compartido a través de un lenguaje compartido
17
2.1.2. La importancia del conocimiento del dominio................................................ 17
2.1.3. El papel de los analistas de negocios ................................................................ 18
2.1.4. Un progreso en curso ........................................................................................ 18
2.2. Ganando el dominio con expertos de dominio ........................................................ 18
2.2.1. Expertos en dominio vs. Grupos de Interes .................................................... 19
2.2.2. Deeper understanding for the business ........................................................... 20
2.2.3. Engaging with your domain experts ................................................................ 20
2.3. Patterns for effective knowledge crunching ............................................................ 20
 2.3.1. Focus on the most interesting conversations ................................................... 20
2.3.2. Start from the use cases .................................................................................... 20
2.3.3. Ask powerful questions ..................................................................................... 20
2.3.4. Sketching ............................................................................................................ 20
2.3.5. Class responsibility collaboration cards .......................................................... 20
2.3.6. Defer the naming of concepts in your model................................................... 20
2.4. Look for existing models ........................................................................................... 20
3. Focusing on the core domain ............................................................................................ 20
3.1. Why decompose a problem domain? .......................................................................... 20
3.2. How to capture the essence of the problem ................................................................. 20
3.3. How to focus on the core problem .............................................................................. 20
3.4. How subdomains shape a solution .............................................................................. 21
3.5. Not all parts of a system will be well designed ........................................................... 21
3.6. What if you have no core domain? .............................................................................. 21
3.7. ||The salient points ....................................................................................................... 21
4. Model-driven design.......................................................................................................... 21
4.1. What is domain model? ............................................................................................... 21
4.2. Model –driven design .................................................................................................. 21
4.3. Using a ubiquitous language to bind the analysis to the code model .......................... 21
4.4. Collaborating on a ubiquitous language ...................................................................... 22
4.5. How to create effective domain models ...................................................................... 22
4.6. When to apply model-driven design ........................................................................... 22
4.7. The salient points ........................................................................................................ 22
5. Patrones de implementación del modelo de dominio ..................................................... 22
5.1. La capa de dominio ..................................................................................................... 22
5.2. Modelos de aplicación del modelo de dominio ........................................................... 23
5.3. Los puntos salientes .................................................................................................... 28
6. Mantenimiento de la integridad de los modelos de dominio con contextos delimitados
29
6.1. Los desafíos de un modelo único ................................................................................ 29
7. Capitulo 7:.......................................................................................................................... 31
8. Capitulo 8: Application architecture ............................................................................... 32
9. Capitulo 9: common problems for teams starting out with domain-driven design..... 33
10. Capitulo 10:.................................................................................................................... 35
Figura 1: Complejidad en SOFTWARE ........................................................................................... 5
Figura 2: Rotura de Código ............................................................................................................ 6
Figura 3: Aplicando los patrones estratégicos del diseño impulsado por dominios. .................. 10
Figura 4: Crujido del Conocimiento ............................................................................................. 17
Figura 5: Los roles de los interesados, expertos en el dominio y el equipo de desarrollo ......... 19
Figura 6: El código que representa el modelo de dominio constituye solo una pequeña parte de
la base de código general. ........................................................................................................... 23
Figura 7: Múltiples modelos de dominio implementados en varios patrones dentro de una
aplicación. ................................................................................................................................... 24
Figura 8: El patrón de script de transacción UML. ...................................................................... 26
1. ¿Qué es el diseño impulsado por dominio?
1.1. Los desafíos de crear software para dominios de problemas
complejos
El patrón de diseño arquitectónico de software más popular para aplicaciones
comerciales es el patrón Big Ball of Mud (BBoM).

La definición de BBoM, según la definición de Brian Foote y Joseph Yoder

en el documento "Big Ball of Mud", es "... una estructura al azar, en expansión,
descuidada, con cinta de ducto y cinta de balas, spaghetti code jungle".

Foote y Yoder usan el término BBoM para describir una aplicación que
parece no tener una arquitectura distinguible (piense en un tazón grande de
espaguetis versus plato de lasaña en capas).

El problema de permitir que el software se disuelva en un BBoM se hace

evidente cuando los cambios rutinarios en el flujo de trabajo y las mejoras de
pequeñas características se convierten en un desafío para implementar debido
a las dificultades para leer y comprender el código base existente.

Una de las principales razones por las que el software se vuelve complejo y
difícil de administrar se debe a la mezcla de complejidades de dominio con
complejidades técnicas, como se ilustra en la Figura 1.
 Complejidad de la Complejidad de
lógica de dominio base de código
heredada

Complejida
d del
Software
Solución técnica de
Líneas Complejidad
borrosas

Figura 1: Complejidad en SOFTWARE

1.1.1. Código creado sin un lenguaje común

La falta de enfoque en un lenguaje compartido y el conocimiento
del dominio del problema dan como resultado una base de código
que funciona, pero no revela la intención del negocio. Esto hace
que las bases de código sean difíciles de leer y mantener porque
las traducciones entre el modelo de análisis y el modelo de código
pueden ser costosas y propensas a errores.

1.1.2. A falta de organización

Como se destaca en la Figura 2, la encarnación inicial de un
sistema que se parece a BBoM es rápida de producir y, a menudo,
un éxito bien redondeado, pero debido a que hay poco enfoque
basado en el diseño de una aplicación en torno a un modelo del
dominio del problema, subsiguiente Las mejoras son
problemáticas.

El código base carece de la sinergia requerida con el

comportamiento empresarial para hacer que el cambio sea
manejable.

Las complejidades del dominio del problema a menudo se mezclan

con las complejidades accidentales de la solución técnica.
 La encarnación inicial Con el tiempo, sin cuidado
del software es rápida de ni consideración, el software
producir. se convierte en bola de
barro.

Figura 2: Rotura de Código

1.1.3. El patrón de bola de barro ahoga el desarrollo

Continuar persistiendo con un patrón arquitectónico similar a un
espagueti puede llevar a un ritmo lento de mejora de
características.

Cuando se lanzan nuevas versiones del producto, pueden tener

errores debido al desorden ininteligible de la base de código con la
que los desarrolladores deben lidiar. Con el tiempo, el equipo de
desarrollo se queja cada vez más de la dificultad de trabajar en este
tipo de desorden.

Al final, exasperado por la situación, se otorga la solicitud para la

temida reescritura de la aplicación. Sin el debido cuidado y
consideración, sin embargo, incluso el proyecto de campo verde
puede fallar en los mismos problemas que crearon el BBoM
original.

En última instancia, BBoM es una mala noticia para usted como

desarrollador porque es una base de código desordenada y
propensa a errores con la que odia tratar. Y son malas noticias para
la empresa porque reduce su capacidad para entregar rápidamente
valor comercial.
 1.1.4. Falta de enfoque en el dominio del problema
Los proyectos fallan cuando no entiendes el dominio empresarial
en el que estás trabajando lo suficientemente bien.

Aparte de los requisitos no funcionales, crear y mantener un

modelo de software útil del dominio que pueda cumplir con los
casos de uso comercial es la parte difícil.

Sin embargo, cuanto más invierta en la comprensión de su dominio

empresarial, mejor equipado estará cuando intente modelarlo en
software para resolver sus problemas empresariales inherentes.

1.2. Cómo las patronas de diseño con dominio gestionan la

complejidad
DDD se enfrenta tanto al desafío de comprender un dominio de problemas como a
crear una solución mantenible que sea útil para resolver problemas dentro de
él. Esto se logra utilizando una serie de patrones estratégicos y tácticos.

1.2.1. Los patrones estratégicos de la DDD

Los patrones estratégicos de DDD destilan el dominio del
problema y dan forma a la arquitectura de una aplicación.

1.2.1.1. Destilar el dominio del problema para revelar lo que es

importante
No todas las necesidades de un producto de software
grande deben estar perfectamente diseñadas; de hecho,
tratar de hacerlo sería una pérdida de esfuerzo. Los equipos
de desarrollo y los expertos en dominios utilizan patrones
de análisis.

El dominio central es la fuerza impulsora detrás del

producto en desarrollo; Es la razón fundamental por la que
se está construyendo.

DDD enfatiza la necesidad de concentrar el esfuerzo y el

talento en el (los) subdominio (s) central (es), ya que esta
es el área que tiene más valor y es clave para el éxito de la
aplicación.
1.2.1.2. Creando un modelo para resolver problemas de
dominio
En el espacio de soluciones, se construye un modelo de
software para cada subdominio para manejar los problemas
de dominio y para alinear el software con los contornos
empresariales. Para evitar la complejidad técnica
accidental, el modelo se mantiene aislado del código de
infraestructura.

Todos los modelos no son creados iguales; Los patrones de

diseño más apropiados se utilizan en función de las
necesidades de complejidad de cada subdominio en lugar
de aplicar un diseño general a todo el sistema.

Los modelos para subdominios que no son fundamentales

para el éxito del producto o que no son tan complejos no
tienen por qué basarse en diseños ricos orientados a
objetos, sino que pueden utilizar arquitecturas más basadas
en procedimientos o en datos.

1.2.1.3. Uso de un lenguaje compartido para habilitar la

colaboración de modelado
Los modelos se construyen a través de la colaboración de
expertos en dominios y el equipo de desarrollo.

La comunicación se logra utilizando un lenguaje

compartido en constante evolución conocido como el
lenguaje ubicuo (UL) para conectar de manera eficiente y
efectiva un modelo de software a un modelo de análisis
conceptual.

El modelo de software está vinculado al modelo de análisis

utilizando los mismos términos de UL para su estructura y
diseño de clase.
1.2.1.4. Aislar los modelos de la ambigüedad y la corrupción
Los modelos se encuentran dentro de un contexto acotado,
lo que define la aplicabilidad del modelo y asegura que se
mantenga su integridad. Los modelos más grandes se
pueden dividir en modelos más pequeños y se pueden
definir dentro de contextos delimitados separados donde
existe ambigüedad en la terminología o donde varios
equipos trabajan para reducir aún más la complejidad.

Los contextos delimitados se utilizan para formar un límite

protector alrededor de los modelos que ayuda a evitar que
el software se convierta en un BBoM. Esto se logra al
permitir que los diferentes modelos de la solución global
evolucionen dentro de contextos de negocios bien
definidos sin tener un impacto negativo en otras partes del
sistema.

Compare el diagrama en la Figura 3 con la Figura 2. El

diagrama muestra cómo se han aplicado los patrones
estratégicos de DDD al software para administrar el gran
dominio de problemas y proteger los modelos discretos
dentro de él.
 Cada contexto del sistema
La parte central del
se integra a través de
sistema se ha identificado
interfaces y límites bien
y aislado para que pueda
pensados
invertirse y evolucionar
de forma independiente
Bola pequeña de barro,
pero está bien ya que es de
baja complejidad y está
aislada para evitar la
corrupción en otros
contextos

El dominio de grandes
problemas se divide en
subdominios para facilitar
su comprensión. Se crea
un modelo en un contexto
para cada subdominio
Los datos de un contexto
se separan para forzar la
integración a través de los
contextos de objeto.

Figura 3: Aplicando los patrones estratégicos del diseño impulsado por dominios.

1.2.1.5. Comprender las relaciones entre contextos

DDD entiende la necesidad de garantizar que los equipos y
la empresa tengan claro cómo funcionan juntos los
modelos y contextos separados para resolver problemas de
dominio que se extienden a través de subdominios.

Los mapas de contexto te ayudan a entender la imagen más

grande; permiten a los equipos comprender qué modelos
existen, de qué son responsables y dónde se encuentran sus
límites de aplicabilidad. Estos mapas revelan cómo
interactúan los diferentes modelos y qué datos
intercambian para cumplir con los procesos de negocios.

1.2.2. Los patrones tácticos de DDD

Los patrones tácticos de la DDD, también conocidos como
bloques de construcción modelo, son una colección de patrones
que ayudan a crear modelos efectivos para contextos complejos
limitados.
 Muchos de los patrones de codificación presentados dentro de la
colección de patrones tácticos han sido ampliamente adoptados
antes del texto de Evans y catalogados por Martin Fowler en
Patterns of Enterprise Application Architecture y Erich Gamma,
et al. En patrones de diseño: elementos de software orientado a
objetos reutilizables. Estos patrones no son aplicables a todos los
modelos, y cada uno debe tomarse por su propio mérito con el
estilo arquitectónico correcto aplicado.

1.2.3. El espacio problemático y el espacio de solución

Todos los patrones detallados en esta sección ayudan a administrar
la complejidad de un problema, también conocido como el espacio
del problema o administran la complejidad de la solución, también
conocido como el espacio de la solución.

El espacio del problema, divide el dominio del problema en

subdominios más manejables. El impacto de DDD en el espacio
del problema es revelar qué es importante y dónde enfocar el
esfuerzo. En el siguiente capítulo veremos con más detalle los
patrones que pueden ayudar a reducir la complejidad en el espacio
del problema.

El lado de la solución de DDD, cubre los patrones que pueden dar

forma a la arquitectura de sus aplicaciones y facilitar su
administración.

1.3. Las prácticas y principios del diseño dirigido por dominio

Si bien hay muchos patrones de DDD, hay una serie de prácticas y principios
rectores que son clave para el éxito con su filosofía. Estos principios clave,
que forman la esencia de DDD, a menudo se pasan por alto, ya que se pone
demasiado énfasis en los patrones de diseño táctico que se utilizan para crear
modelos de software.

1.3.1. Centrándose en el dominio central

DDD enfatiza la necesidad de enfocar el mayor esfuerzo en el
subdominio central. El subdominio central es el área de su
producto que será la diferencia entre ser un éxito y un fracaso. Es
 el único punto de venta del producto, la razón por la cual se está
construyendo en lugar de comprarlo. El dominio central es el área
del producto que le dará una ventaja competitiva y generará un
valor real para su negocio. Es vital que todo el equipo entienda cuál
es el dominio central.

1.3.2. Aprendizaje a través de la colaboración

DDD destaca la importancia de la colaboración entre los equipos
de desarrollo y los expertos de negocios para producir modelos
útiles para resolver problemas. Sin esta colaboración y el
compromiso de los expertos en negocios, gran parte del
intercambio de conocimientos no podrá llevarse a cabo, y los
equipos de desarrollo no obtendrán una visión más profunda del
dominio del problema. También es cierto que, a través de la
colaboración y el procesamiento de los conocimientos, la empresa
tiene la oportunidad de aprender mucho más sobre su dominio.

1.3.3. Creando modelos a través de la exploración y

experimentación
DDD trata los modelos de análisis y código como uno solo. Esto
significa que el modelo de código técnico está vinculado al modelo
de análisis a través de la UL compartida. Un avance en el modelo
de análisis da como resultado un cambio en el modelo de código.
Una refactorización en el modelo de código que revela una visión
más profunda se refleja nuevamente en el modelo de análisis y los
modelos mentales del negocio.

Los avances solo se producen cuando los equipos tienen tiempo

para explorar un modelo y experimentar con su diseño. Dedicar
tiempo a la creación de prototipos y la experimentación puede
hacer mucho para ayudarlo a diseñar un mejor diseño.

1.3.4. Comunicación
La capacidad de describir con eficacia un modelo creado para
representar un dominio problemático es la base de DDD. Por eso,
sin lugar a dudas, la faceta más importante de DDD es la creación
 de UL. Sin un lenguaje compartido, la colaboración entre la
empresa y los equipos de desarrollo para resolver problemas no
sería efectiva. El análisis y los modelos mentales producidos en
sesiones de análisis de conocimientos entre los equipos necesitan
un lenguaje compartido para vincularlos a una implementación
técnica.

Sin una forma efectiva de comunicar ideas y soluciones dentro

de un dominio de problemas, no se pueden lograr avances en el
diseño.

1.3.5. Entendiendo la aplicabilidad de un modelo

Cada modelo que se construye se entiende dentro del contexto de
su subdominio y se describe utilizando el UL. Sin embargo, en
muchos modelos grandes, puede haber ambigüedad dentro de la
UL, con diferentes partes de una organización que tienen diferentes
entendimientos de un término o concepto común.

El DDD aborda esto al garantizar que cada modelo tenga su propio

UL que sea válido solo en un contexto determinado.

Cada contexto define un límite lingüístico; Asegurar que los

modelos se entiendan en un contexto específico para evitar la
ambigüedad en el lenguaje. Por lo tanto, un modelo con términos
superpuestos se divide en dos modelos, cada uno claramente
definido dentro de su propio contexto. En el lado de la
implementación, los patrones estratégicos pueden imponer estos
límites lingüísticos para permitir que los modelos evolucionen de
manera aislada. Estos patrones estratégicos dan como resultado un
código organizado que puede admitir cambios y reescrituras.

1.3.6. En constante evolución del modelo

Cualquier desarrollador que trabaje en un sistema complejo puede
escribir un buen código y mantenerlo por un corto tiempo. Sin
embargo, sin la sinergia entre el código fuente y el dominio del
problema, el desarrollo continuo probablemente terminará en una
base de código que es difícil de modificar, lo que resulta en un
 BBoM. DDD ayuda con este problema poniendo énfasis en el
equipo para ver continuamente qué tan útil es el modelo para el
problema actual. Desafía al equipo a evolucionar y simplificar
modelos complejos de dominios a medida que obtiene información
sobre el dominio.

El DDD aún no es una bala de plata y requiere dedicación y

constante procesamiento de conocimientos para producir software
que se pueda mantener durante años y no solo meses. Los nuevos
casos de negocios pueden romper un modelo anteriormente útil o
pueden requerir cambios para hacer más explícitos los conceptos
nuevos o existentes.

1.4. Errores en el diseño basado en el dominio

DDD no es una metodología estricta en sí misma, pero debe usarse con algún
tipo de metodología de proyecto de software iterativo para construir y
desarrollar un modelo útil.

1.4.1. Los patrones tácticos son la clave para DDD

DDD no es un libro sobre diseño orientado a objetos, ni es una
filosofía centrada en el código o un lenguaje de patrones. Sin
embargo, si busca en los web artículos sobre DDD, se lo confundirá
con pensar que es solo un puñado de patrones de implementación,
ya que la mayoría de los artículos y blogs sobre DDD se centran en
los patrones de modelado.

1.4.2. DDD es un marco

DDD no requiere un marco especial o base de datos. El modelo
implementado en el código sigue el principio aPOCO (Plain Old C
# Object) que garantiza que carece de cualquier código de
infraestructura para que nada se distraiga de su propósito centrado
en el dominio. Una metodología orientada a objetos es útil para
construir modelos, pero de ninguna manera es obligatoria.
 1.4.3. DDD es una bala de plata
DDD puede requerir mucho esfuerzo, requiere una metodología de
desarrollo iterativo, un negocio comprometido, y desarrolladores
inteligentes. Todos los proyectos de software pueden beneficiarse
de las prácticas de análisis de DDD, como la destilación del
dominio del problema y los patrones estratégicos, como el
aislamiento de un modelo de código.

Eso representa la lógica del dominio. Sin embargo, no todos

requieren los patrones tácticos de DDD para construir un modelo
de dominio enriquecido. Los dominios triviales no garantizan el
nivel de sofisticación ya que tienen poca o ninguna lógica de
dominio. Por ejemplo, sería una pérdida de tiempo y costoso
aplicar todos los patrones de DDD al crear una aplicación de blog
simple.

1.5. The Salient Points

 DDD valora un enfoque en el dominio central, la colaboración y la
exploración con expertos en dominios, la experimentación para producir
un modelo más útil y la comprensión de los diversos contextos en juego
en un dominio de problemas complejos.
 DDD no es un lenguaje de patrones, es una filosofía de colaboración
centrada en la entrega, con la comunicación desempeñando un papel
central.
 DDD es un enfoque del desarrollo de software centrado en el idioma y el
dominio.
 Se utiliza un lenguaje ubicuo para vincular el modelo de análisis al modelo
de código para que el equipo de desarrollo y los expertos en dominios
colaboren en el diseño de un modelo. Aprender y crear un idioma para
comunicarse sobre el dominio del problema es el proceso de DDD. El
código es el artefacto.
 Para conservar la integridad de un modelo, se define dentro de un contexto
acotado. El modelo está aislado de las preocupaciones de infraestructura
de la aplicación para separar las complejidades técnicas de las
complejidades del negocio.
2. Destilar el dominio del problema
Este capítulo presenta métodos para facilitar la destilación del conocimiento del
dominio con el fin de comprender mejor el dominio del problema, lo que le
permitirá construir un modelo de dominio efectivo. También se presentan métodos
para extraer información importante sobre los comportamientos de una aplicación
junto con técnicas para descubrir información detallada dentro del dominio del
problema.

2.1. Conocimiento y colaboración

La recopilación de conocimientos se produce en las pizarras blancas,
trabajando con ejemplos con expertos en negocios y, en general,
intercambiando ideas. Es la búsqueda para descubrir y acordar una
comprensión compartida del dominio del problema para producir un modelo
que pueda cumplir con los casos de uso empresarial. El proceso de
procesamiento de conocimientos, como se muestra en la Figura, comienza
con los comportamientos de un sistema.

El equipo analiza los escenarios de la aplicación con las partes interesadas y

los expertos del negocio. Este proceso es el catalizador para la conversación,
una visión profunda y una comprensión compartida del dominio para todos
los participantes. Por lo tanto, es vital que las partes interesadas y los expertos
en la materia estén activamente involucrados y comprometidos.
 Problema de
Simplifique el modelo a medida
Dominio
que entiendo más sobre el dominio
del problema.
Expertos en
negocios

Caso de Uso de Crujido del

Negocio conocimiento

Comenzar con un caso Un modelo útil que satisface las

de uso / historia / necesidades del caso de uso.
escenario Equipo de desarrollo

Figura 4: Crujido del Conocimiento

2.1.1. Alcanzar un entendimiento compartido a través de un

lenguaje compartido
Una salida del procesamiento de conocimientos y un artefacto de
la comprensión compartida es un lenguaje ubicuo (UL) común. Al
modelar con partes interesadas y expertos en la materia, todos
deben hacer un esfuerzo consciente para aplicar de manera
consistente un lenguaje compartido rico en terminología específica
de dominio. Este lenguaje debe hacerse explícito y usarse al
describir el modelo de dominio y el dominio de problemas. El
lenguaje también debe usarse en la implementación del código del
modelo, con los mismos términos y conceptos que se usan como
nombres de clase, propiedades y nombres de métodos.

2.1.2. La importancia del conocimiento del dominio

El conocimiento del dominio es clave, incluso más que el
conocimiento técnico. Los equipos que trabajan en una empresa
con procesos y lógica complejos deben sumergirse en el dominio
del problema y, como una esponja, absorber todo el conocimiento
relevante del dominio.
 Esta visión permitirá a los equipos centrarse en el resalte los
puntos y cree un modelo en el corazón de la base de código de su
aplicación que pueda cumplir con los casos de uso del negocio y
seguir haciéndolo durante la vida útil de la aplicación.

2.1.3. El papel de los analistas de negocios

Puede parecer que el papel del analista de negocios tradicional ya
no es necesario en el mundo de DDD; Sin embargo, éste no es el
caso. Un analista de negocios aún puede ayudar a las partes
interesadas a desarrollar sus ideas iniciales y capturar las entradas
y salidas del producto. Si tiene extraños desarrolladores de niños
pequeños y está nervioso por ponerlos frente a expertos en
dominios, también puede usar analistas de negocios como
facilitadores para ayudar a la comunicación. Lo que no desea hacer
es eliminar la comunicación directa entre el equipo de desarrollo y
las personas que más entienden esa parte del negocio.

2.1.4. Un progreso en curso

El crujido del conocimiento es un proceso continuo; los equipos
deben trabajar continuamente para obtener una vista simple del
dominio del problema que se centre solo en las piezas relevantes
para ayudar a la creación de un modelo útil. Como aprenderá en el
Capítulo 4, el diseño basado en modelos y la evolución de un
modelo de dominio es un proceso continuo. Se deben rechazar
muchos modelos para garantizar que tenga un modelo útil para los
casos de uso actuales de un sistema. La colaboración entre el
equipo de desarrollo, las partes interesadas del negocio y los
expertos en la materia no debe limitarse al inicio de un proyecto.

El procesamiento de conocimientos debe ser una preocupación

constante con el negocio involucrado a lo largo de la vida útil de la
creación de la aplicación.

2.2. Ganando el dominio con expertos de dominio

La colaboración entre la empresa y el equipo de desarrollo es un aspecto
esencial de DDD y es crucial para el éxito de un producto en desarrollo. Sin
embargo, es importante buscar a aquellos que son expertos en la materia en
el dominio en el que está trabajando y que pueden ofrecerle una visión más
profunda del área del problema. DDD se refiere a estos expertos en la materia
como expertos de dominio.

2.2.1. Expertos en dominio vs. Grupos de Interes

En espacio de problemas le proporciona un conjunto de requisitos,
entradas y salidas esperadas; esto generalmente se proporciona a
través de sus partes interesadas. Un espacio de solución contiene
un modelo que puede satisfacer las necesidades de los requisitos;
aquí es donde los expertos en dominios pueden ayudar.

Como se muestra en la Figura, si su interlocutor no es un experto

en dominio, su función será muy diferente de la de un experto en
dominios. Un actor le dirá lo que quiere que haga el sistema; Se
centrarán en las entradas y salidas. Por otro lado, un experto en
dominios trabajará con usted para producir un modelo útil que
pueda satisfacer las necesidades de un actor y los comportamientos
de la aplicación.

Figura 5: Los roles de los interesados, expertos en el dominio y el equipo de desarrollo

 2.2.2. Deeper understanding for the business
2.2.3. Engaging with your domain experts

2.3. Patterns for effective knowledge crunching

2.3.1. Focus on the most interesting conversations
2.3.2. Start from the use cases
2.3.3. Ask powerful questions
2.3.4. Sketching
2.3.5. Class responsibility collaboration cards
2.3.6. Defer the naming of concepts in your model
2.1.1 Behavior-driven development

2.1.2 Rapid prototyping

2.1.3 Look at Paper-Based Systems

2.4. Look for existing models

2.1.4 Understanding intent

2.1.5 Event storming

2.1.6 Impact Mapping

2.1.7 Understanding the business model

2.1.8 Deliberate discovery

2.1.9 Model exploration whirlpool

2.2 The salient points

3. Focusing on the core domain

3.1. Why decompose a problem domain?
3.2. How to capture the essence of the problem
3.1.1 Look beyond requirements

3.1.2 Capture the domain vision for a shared understanding of what is core

3.3. How to focus on the core problem

3.1.3 Distilling a problem domain
 3.1.4 Core domains

3.1.5 Treat your core domain as a product rather than a project

3.1.6 Generic domains

3.1.7 Supporting domains

3.4. How subdomains shape a solution

3.5. Not all parts of a system will be well designed
3.1.8 Focus on clean boundaries over perfect models

3.1.9 The core domain doesn’t always have to be a perfect the first time

3.1.10 Build subdomains for replacement rather than reuse

3.6. What if you have no core domain?

3.7. ||The salient points

4. Model-driven design
4.1. What is domain model?
4.1.1 The domain versus the domain model

4.1.2 The analysis model

4.1.3 The code model

4.1.4 The code model is the primary expression of the domain model

4.2. Model –driven design

4.1.5 The challenges with upfront design

4.1.6 Team modeling

4.3. Using a ubiquitous language to bind the analysis to the code

model
4.1.7 A language will outlive your software

4.1.8 That language of the business

4.1.9 Translation between the developers and the business

4.4. Collaborating on a ubiquitous language
4.1.10 Carving out a language by working with concrete examples

4.1.11 Teach your domain experts to focus on the problem and not jump to a
solution

4.1.12 Best practices for shaping the language

4.5. How to create effective domain models

4.1.13 Don’t let the truth get in the way of a good model

4.1.14 Model only what is relevant

4.1.15 Domain models are temporarily useful

4.1.16 Be explicit with terminology

4.1.17 Limit your abstractions

4.1.17.1 Focus your code at the right level of abstraction

4.1.17.2 Abstract behavior not implementations

4.1.17.3 Implement the model in code early and often

4.1.17.4 Don’t stop at the first good idea

4.6. When to apply model-driven design

4.1.18 If it’s not worth the effort don’t try and model it

4.1.19 Focus on the core domain

4.7. The salient points

5. Patrones de implementación del modelo de dominio

5.1. La capa de dominio
Es el área de código que contiene el modelo de dominio. Aísla las
complejidades del modelo de dominio de las complejidades técnicas
accidentales de la aplicación. Es responsable de garantizar que los problemas
de infraestructura, como la gestión de transacciones y el estado persistente, no
se mezclen con los problemas de negocios y borren las reglas que existen en
 el dominio. Constituye solo una pequeña parte de la aplicación. El resto está
lleno de responsabilidades de infraestructura y presentación, como puede ver
en la Figura:

Figura 6: El código que representa el modelo de dominio constituye solo una pequeña parte de la base de código
general.

5.2. Modelos de aplicación del modelo de dominio

Existen varios patrones a su disposición para implementar un modelo de
dominio en código. No todos los sistemas grandes están construidos de la
misma manera. Algunas partes son menos importantes que otras, y existen
múltiples modelos para servir a diferentes contextos. Figura:
Figura 7: Múltiples modelos de dominio implementados en varios patrones dentro de una aplicación.

Muestra múltiples modelos coexistiendo en una aplicación. Esto se debe a que

se requieren diferentes modelos para diferentes contextos o equipos diferentes
que trabajan en modelos separados. Así mismo, muestra un ejemplo de cómo
se puede segmentar una aplicación grande en contextos con diferentes
patrones utilizados para representar el modelo de dominio.

5.1.1 Modelo de Dominio

Catalogado en los Patrones de Arquitectura de Aplicaciones

Empresariales de Martin Fowler, es sinónimo de DDD porque es un
buen ajuste para dominios complejos con lógica empresarial rica. El
modelo de dominio es un modelo orientado a objetos que incorpora
tanto el comportamiento como los datos. A primera vista, puede
reflejar el modelo de persistencia de datos (esquema de datos si está
utilizando una base de datos relacional). Aunque ambos contienen
datos, el modelo de dominio también incorpora procesos de negocio
y asociaciones, reglas y lógica de dominio enriquecida. El patrón del
 modelo de dominio se basa en la premisa de que no hay una base de
datos; por lo tanto, puede evolucionar y ser creado de una manera
completamente persistente e ignorante. Al diseñar el modelo, no
comienza con un modelo de datos; en su lugar, comienza con el
modelo de código: basado en el modelo en lugar de en el diseño
basado en datos.

Por ejemplo, si estuviera construyendo una tienda de comercio

electrónico, las "cosas" que vivirían en el modelo representarían una
Cesta, Pedido, Artículo de pedido y similares. Estas cosas tienen datos
y, lo que es más importante, tienen comportamiento. Una orden no
solo tendría propiedades que representan una fecha de creación,
estado y número de orden, sino que contendría la lógica de negocios
para aplicar un cupón de descuento, incluidas todas las reglas de
dominio que lo rodean: ¿Es válido el cupón? ¿Se puede utilizar el
cupón con los productos en la cesta? ¿Hay otras ofertas en vigor que
invaliden el cupón? Es el más desafiante técnicamente y requiere que
los desarrolladores conozcan bien la programación orientada a
objetos. La mayoría de los subsistemas están basados en CRUD, y
solo el dominio central requiere el patrón de implementación del
modelo de dominio para garantizar la claridad o para administrar la
lógica compleja. Lo que no debes hacer es tratar de aplicar el patrón
de modelo de dominio para todo.

5.1.2 Script de Transcripción

Sigue un estilo de desarrollo de procedimiento en lugar de un enfoque

orientado a objetos. Por lo general, se crea un solo procedimiento para
cada una de sus transacciones comerciales, y se agrupa en algún tipo
de administrador estático o clase de servicio. Cada procedimiento
contiene toda la lógica empresarial que se requiere para completar la
transacción comercial desde el flujo de trabajo, las reglas comerciales
y las comprobaciones de validación hasta la persistencia en la base de
datos. La siguiente figura, muestra la firma de ejemplo de una interfaz
que está implementando el patrón de script de transacción. Las dos
implementaciones contienen toda la lógica que requieren para
 manejar los casos comerciales de crear una subasta y hacer una oferta
en una subasta, respectivamente, incluido el acceso a los datos y la
lógica de persistencia, la autorización, la concurrencia transaccional y
los problemas de coherencia.

Figura 8: El patrón de script de transacción UML.

5.1.3 Modulo de Tabla

Módulo de tabla

El patrón de módulo de tabla asigna el modelo de objeto al modelo

de base de datos. Un solo objeto representa una tabla o vista en la base
de datos. El objeto es responsable de todas las necesidades de
persistencia junto con el comportamiento de la lógica empresarial. La
ventaja de este patrón es que no existe una discrepancia entre el
modelo de objetos y el modelo de base de datos. El patrón del módulo
de la tabla es ideal para el diseño impulsado por la base de datos.

5.1.4 Registro Activo

Es una variación del patrón del módulo de tabla que asigna objetos a
filas de una tabla en lugar de tener objetos que representan las tablas
en sí. Un objeto representa una fila de la base de datos (registro) en un
estado transitorio o bajo modificación.
 El patrón de registro activo es un patrón popular que es especialmente
efectivo cuando su modelo de base de datos subyacente coincide con
su modelo de negocio. El patrón de registro activo es ideal para
aplicaciones simples que tienen una asignación de uno a uno entre el
modelo de datos y el modelo de negocios, como un blog o un motor
de foro; también es un buen patrón para usar si tiene un modelo de
base de datos existente.

5.1.5 Modelo de dominio anémico

Se conoce como un anti-patrón. A primera vista, el patrón es muy

similar al modelo de dominio en el sentido de que todavía encontrará
objetos de dominio que representan el dominio de negocios. Cualquier
comportamiento, sin embargo, no está contenido dentro de los objetos
del dominio. En su lugar, se encuentra fuera del modelo, dejando los
objetos del dominio como clases simples de transferencia de datos. La
principal desventaja de este patrón es que los servicios de dominio
asumen el papel de un estilo de código más procedimental. El patrón
de modelo de dominio anémico es un buen candidato para partes de
su modelo de dominio que tienen poca lógica o para equipos que no
tienen mucha experiencia con técnicas de programación orientadas a
objetos. Puede incorporar el UL y ser un buen primer paso cuando se
trata de crear un modelo de dominio rico.

5.1.6 Modelo de dominio anémico y programación funcional

Es en realidad un concepto fundamentalmente útil cuando se utiliza la

programación funcional en lugar de ser un antipatrón.

Puede parecer contradictorio que los modelos de dominio estén ahí

para facilitar las conversaciones con los expertos en dominios, y sin
embargo, el modelo de modelo de dominio anémico impide la
capacidad de representar conceptos de dominio como objetos. Al crear
modelos de dominio funcionales, todavía es posible tener estructuras
que representan conceptos de dominio, incluso cuando se utiliza el
modelo de modelo de dominio anémico. Sin embargo, de manera
significativa, solo son estructuras de datos sin comportamiento, por lo
 que son una entidad BankAccount rica en comportamiento y orientada
a objetos.

5.3. Los puntos salientes

➤ La capa de dominio contiene el modelo del dominio y está aislada de las
preocupaciones de infraestructura y presentación.

➤ El modelo de dominio se puede implementar con múltiples patrones de

lógica de dominio.

➤ Puede haber más de un modelo en juego en un proyecto grande y, por lo

tanto, más de un solo patrón para representar la lógica del dominio.

➤ El patrón del modelo de dominio es un buen ajuste para un dominio de

problema complejo. Los conceptos en el dominio se encapsulan como objetos
que contienen datos y comportamiento.

➤ El patrón de script de transacción organiza toda la lógica del dominio para

cumplir con una transacción comercial o un caso de uso en un módulo de
procedimiento.

➤ El patrón del módulo de tabla representa su modelo de datos en forma de

objeto. El módulo de tabla es útil para los modelos controlados por datos que
reflejan el esquema de datos subyacente.

➤ El patrón de registro activo es como el patrón del módulo de tabla, ya que

está controlado por datos pero representa filas en tablas en lugar de las tablas
en sí. Es un buen ajuste para la lógica de baja complejidad pero para los
modelos basados en CRUD.

➤ Un modelo anémico es similar al patrón del modelo de dominio; Sin

embargo, el modelo carece de cualquier comportamiento. Es puramente un
modelo del estado de un objeto; todo comportamiento reside en las clases de
servicio que modifican. La programación funcional es un enfoque igualmente
válido para construir modelos de dominio.
 ➤ Al usar la programación funcional, los comportamientos pueden agruparse
en agregados (que representan conceptos de dominio) y aplicarse a estructuras
de datos puras e inmutables (que también representan conceptos de dominio).

6. Mantenimiento de la integridad de los modelos de

dominio con contextos delimitados
6.1. Los desafíos de un modelo único
En el núcleo del diseño impulsado por dominios está la necesidad de crear
modelos explícitos y evolutivos en código que se alineen con los modelos
conceptuales compartidos. A medida que se obtienen nuevos conocimientos
de dominio, se pueden incorporar de manera eficiente al modelo. Sin embargo,
si se utiliza un solo modelo para un sistema completo, los conceptos de un
área del modelo se pueden confundir con conceptos de sonido similar de otra
área del sistema.

6.1.1 Un modelo puede crecer en complejidad

Los modelos grandes acomodan muchos conceptos de dominio y

llevan a cabo muchos casos de uso empresarial. Como consecuencia,
es fácil cometer errores y agrupar los conceptos equivocados.
También puede ser muy difícil encontrar lo que está buscando. Cuanto
más crece el sistema, más graves son estos problemas, lo que reduce
la velocidad a la que se pueden agregar nuevas funciones y mejoras.

6.1.2 Equipos múltiples trabajando en un solo modelo

El código complejo es solo uno de los problemas que surgen de un

solo modelo. La sobrecarga de colaboración y las ineficiencias
organizativas también son problemas importantes que un modelo
monolítico puede causar. Como un equipo desea lanzar una nueva
función, debe verificar con otros equipos que sus cambios también
pueden implementarse. O el primer equipo tendrá que esperar o se
utilizarán estrategias de ramificación complejas.

6.1.3 La ambigüedad en el lenguaje del modelo

 Algunos conceptos en un sistema son muy similares, incluso podrían
tener el mismo nombre. Sin embargo, en realidad, significan cosas
muy diferentes para diferentes partes del negocio. Como figura, el
concepto de "Boleto" significa cosas diferentes para las Ventas y el
Cliente. Una vez que acepta que los nombres pueden tener diferentes
significados en diferentes contextos, es más fácil aceptar que
múltiples modelos más pequeños son más efectivos que uno solo
grande.

6.1.4 La aplicabilidad de un concepto de dominio

A veces, una sola entidad física en el dominio del problema puede ser
clasificada erróneamente como un concepto único en el código. Esto
es problemático cuando la entidad física en realidad representa
múltiples conceptos, que cada uno significa cosas diferentes en
contextos diferentes. Por ejemplo, los productos tienen diferentes
significados en diferentes contextos. Es un concepto que debe
adquirirse con un margen de tabla de resultados y un tiempo de
entrega aceptable para el equipo de Adquisiciones. Sin embargo, para
el equipo de ventas, un producto es un concepto con imágenes, guías
de tamaño y pertenece a una categoría de ventas, ninguna de las cuales
es relevante para el equipo de Adquisiciones, aunque sea la misma
entidad física en el dominio del problema.

6.1.5 Integración con código heredado o código de terceros

 Otra razón para preferir modelos más pequeños es que la integración
con el código heredado o con terceros puede ser menos problemática.
Agregar nuevas funciones a un código base monolítica puede ser
doloroso cuando hay mucho código heredado. Desea agregar modelos
nuevos, claros e intuitivos que haya creado con expertos en dominios,
pero las limitaciones del código heredado pueden restringir la
expresividad de su diseño. Pero si tiene modelos más pequeños, no
todos deberán tocar el código heredado.

6.1.6 Your domain model is not your enterprise model

6.2 Use Bounded contexts to divide and conquer a large model

6.2.1 Defining a models boundary

6.2.1.1 Define boundaries around language

6.2.1.2 Align to business capabilities

6.2.1.3 Create contexts around teams

6.2.1.4 Try to retain some communication between teams

6.2.1.5 context game

6.2.2 The difference between a subdomain and a bounded context

6.3 Implementing bounded contexts

6.4 The salient points

7. Capitulo 7:
7.1 A reality Map

7.1.1 The technical reality

7.1.2 The organizational reality

7.1.3 Mapping a relevant reality

7.1.4 X marks the spot of the core domain

7.2 Recognizing the relationships between bounded contexts

 7.2.1 Anticorruption layer

7.2.2 Shared kernel

7.2.3 Open host service

7.2.4 Separate ways

7.2.5 Partnership

7.2.6 An upstream/downstream relationship

7.2.6.1 Customers-supplier

7.2.6.2 Conformist

7.3 Communicating the context map

7.4 The strategic importance of context maps

7.4.1 retaining integrity

7.4.2 the basis for a plan of attack

7.4.3 understanding ownership and responsibility

7.4.4 revealing areas of confusion in business work flow

7.4.5 identifying nontechnical obstacles

7.4.6 encourages good communication

7.4.7 helps on-board new starters

7.5 The salient points

8. Capitulo 8: Application architecture

8.1 Application architecture

8.1.1 separating the concerns of your application

8.1.2 abstraction from the complexities of the domain

8.1.3 a layered architecture

8.1.4 dependency architecture

 8.1.5 dependency inversion

8.1.6 the domain layer

8.1.7 the application service layer

8.1.8 the infrastructural layers

8.1.9 communication across layers

8.1.10 testing in isolation

8.1.11 don’t share data schema between bounded contexts

8.1.11.1 application architecture versus architectures for bounded

contexts

8.2 Application services

8.2.1 application logic versus domain logic

8.2.2 defining and exposing capabilities

8.2.3 business use case coordination

8.2.4 application services represent use cases, not create, read, update, and
delete

8.2.5 domain layer as an implementation detail

8.2.6 domain reporting

8.2.7 read models versus transactional models

8.3 Application clients

8.4 The salient points

9. Capitulo 9: common problems for teams starting out

with domain-driven design
9.1 Overemphasizing the importance of tactical patterns

9.1.1 using the same architecture for all bounded contexts

9.1.2 striving for tactical pattern perfection

 9.1.3 mistaking the building blocks for the value of DDD

9.1.4 focusing on code rather than the principles of DDD

9.2 Missing the real valued of DDD: collaboration, communication, and context

9.2.1 Producing a big ball of mud due to underestimating the importance of

context

9.2.2 Causing ambiguity and misinterpretations by failing to create a UL

9.2.3 Designing technical-focused solutions due to a lack of collaboration

9.3 Spending too much time on what’s not important making simple problems
complex

9.3.1 applying DDD principles to a trivial domain with little business

expectation

9.3.2 disregarding crud as an antipattern

9.3.3 using the domain model pattern for every bounded context

9.3.4 ask yourself: is it worth this extra complexity?

9.4 Underestimating the cost of applying DDF

9.4.1 trying to succeed without a motivated and focused team

9.4.2 attempting collaboration when a domain expert is not behind the

project

9.4.3 learning in a noniterative development methodology

9.4.4 applying DDD to every problem

9.4.5 sacrificing pragmatism for needless purity

9.4.6 wasted effort by seeking validation

9.4.7 always striving for beautiful code

9.4.8 DDD is about providing value

9.5 The salient points

10. Capitulo 10:
10.1 Selling DDD

10.1.1 education your team

10.1.2 speaking to your business

10.2 Applying the principles of ddd

10.2.1 understand the vision

10.2.2 capture the required behaviors

10.2.2.1 distilling the problem space

10.2.2.2 focus on what is important

10.2.3 understand the reality of the landscape

10.2.4 modeling a solution

10.2.4.1 all problems are not created equal

10.2.4.2 engaging with an expert

10.2.4.3 select a behavior and model around a concrete scenario

10.2.4.4 collaborate with the domain expert on the most interesting

parts

10.2.4.5 evolve ul to remove ambiguity

10.2.4.6 throw away your first model , an your second

10.2.4.7 implement the model in code

10.2.4.8 creating a domain model

10.2.4.9 keep the solution simple and your code boring

10.2.4.10 carve out an area of safety

10.2.4.11 integrate the model early and often

10.2.4.12 nontechnical refactoring

10.2.4.13 decompose your solution space

 10.2.4.14 rinse and repeat

10.3 Exploration and experimentation

10.3.1 challenge your assumptions

10.3.2 modeling is a continuous activity

10.3.3 there are no wrong models

10.3.4 supple code aids discovery

10.4 Making the implicit explicit

10.4.1 tackling ambiguity

10.4.2 give things a name

10.5 A problem solver first, a technologist second

10.5.1 don’t solve all the problems

10.6 How do I know that I am doing it right?

10.6.1 good is good enough

10.6.2 practice, practice, practice

10.7 The salient points