Get best of the week

¿Qué puedo aprender sobre el diseño impulsado por dominio en 10 minutos?

Dicen que puedes mirar el fuego sin cesar, observar cómo funcionan los demás y también estudiar DDD (diseño dirigido por dominio, diseño específico de dominio). Pero si solo tiene 10 minutos, puede leer este artículo y llegar a lo más alto, y luego con una mirada inteligente, asiente con la cabeza durante una pequeña charla.

Torcimos y revisamos DDD desde diferentes ángulos, junto con Andrei Ratushny, director técnico de Ugra Internet Solutions.





Acerca de la empresa: Ugra Internet Solutions es una empresa que se dedica a la automatización de procesos comerciales en los sectores público y comercial. Ubicado en la ciudad de Khanty-Mansiysk. En desarrollo 12 personas.

1. ¿Qué es DDD? Puede explicarse incluso a un niño (o un vendedor)


DDD es un enfoque que tiene como objetivo estudiar el área temática de la empresa en su conjunto o de cualquier proceso comercial individual. Este es un enfoque excelente para proyectos en los que la complejidad (complejidad) de la lógica de negocios es bastante grande. Su uso está diseñado para reducir esta complejidad tanto como sea posible.

Fuera del enfoque DDD, cuando un programador escribe código, presta más atención a las tecnologías y la infraestructura, por ejemplo, cómo enviar un mensaje, cómo recibirlo, codificarlo, guardarlo en una base de datos, qué base de datos.

El enfoque DDD sugiere que todo esto, por supuesto, es importante, pero secundario. El negocio es más importante y debe ser lo primero. Y para hacer que todo esto funcione en conjunto, DDD nos enseña (a los desarrolladores) a hablar el mismo idioma con los negocios. No en un lenguaje de programación, sino en un lenguaje de negocios. Esto se llama en el lenguaje ubicuo DDD.

2. Chip DDD - Contexto limitado


Bounded Context es una herramienta DDD clave; es un límite explícito dentro del cual existe un modelo de dominio. Mapea un solo idioma en un modelo de software. Es en base a los contextos que puede dividir el código en módulos / paquetes / componentes para que los cambios en cada uno de ellos tengan un efecto mínimo (o cero) en los demás.

Para los desarrolladores, este enfoque le permite realizar cambios en el código sin temor a que en algún lugar de otro lugar se rompa algo (por ejemplo, cambie algo en el proceso de pago y no se preocupe de que algo se caiga de los correos debido a esto).

Para los líderes de equipo, este enfoque nos permite paralelizar significativamente el trabajo de los equipos, lo que puede acelerar significativamente el trabajo en el proyecto.

Además de un contexto limitado, hay todo tipo de cosas como mapas contextuales, un solo idioma, relaciones entre contextos, mapas de traducción ... ¡uhhh! No lo contará en 10 minutos, pero puede leer el libro "verde".

3. Libros generales sobre DDD: rojo, azul y verde.


DDD es un enfoque bastante antiguo. Su uso parece razonable y bastante justificado, pero por alguna razón todavía no está muy extendido, se dice poco al respecto en las conferencias. ¿Qué tiene de malo este DDD?

Se supone que el problema principal es la falta de materiales de capacitación. Toda la teoría se describe en varios libros: rojo , azul y verde . Dicen que hay "otro libro rojo" , pero pocos lo han visto todavía :) Los

libros rojo y azul son tan difíciles de percibir que en algún lugar en el medio quiero tirar el libro por la ventana gritando: "Basta de esta mierda de mí, mira este DDD incomprensible! Iré y haré lo que pueda ". Y esto es solo sobre teoría, con materiales sobre práctica es aún más complicado.

Por lo tanto, si aún decide comenzar a estudiar literatura sobre DDD, lo mejor es comenzar con un libro verde. En él, Vaughn Vernon recorre la parte superior del enfoque y, con ejemplos simples, muestra sus ventajas. Dicen que la traducción resultó ser dudosa, por lo que es mejor leerla en el original.

4. Cómo entender que es hora de aplicar DDD


Cuente el número de casos de uso para su sistema. Si están en la región de 10-15, entonces la lógica de negocios no es tan complicada, y no puede usar vapor, no use ningún DDD.

Si tiene 30-50 o más casos UX, y se cruzan mucho, tiene sentido pensar en usar DDD al menos en alguna parte del sistema.

5. Cómo implementar DDD en la empresa de abajo hacia arriba


Imagine que es un desarrollador al que le gusta DDD, y cree que en su empresa este enfoque puede aplicarse para hacer felices a las personas.

Iniciar una introducción guerrillera de DDD solo es difícil. Primero, el conocimiento puede no ser suficiente para comenzar el proceso. En segundo lugar, los tipos de tu equipo pueden pensar que estás haciendo cosas estúpidas y romperán todo al meter palos en las ruedas.

Es mejor comenzar la implementación creando un grupo de iniciativa: intenten el enfoque juntos, comprendan los matices y comprendan en la práctica.

Solo entonces puede ir a un arquitecto o ingeniero técnico para explicarle el valor. Pero recuerde que DDD no es necesario en todas partes. DDD resuelve problemas específicos, por lo que es muy importante no exagerar.

El enfoque tiene un efecto secundario: si las personas incluso comienzan a luchar por DDD, entonces ya comenzarán a actuar en el paradigma de "Divide, divide, reduce la conectividad y sigue la lógica empresarial". Y a partir de esto, comenzarán cambios positivos: en algún lugar el código se escribirá mejor, en algún lugar la velocidad aumentará. Este conocimiento no tiene que convertirse en código en contextos y otros artefactos DDD. El código puede seguir siendo el código, pero mejorará y la velocidad y la calidad aumentarán.

6. Cómo implementar DDD en la empresa de arriba a abajo


  1. Asegúrese de que este enfoque ayudará en un caso particular.
  2. Encuentre una persona en el equipo que tenga habilidades arquitectónicas (él ayudará a determinar en qué parte del sistema se cortarán las costuras).
  3. Invita a practicantes de DDD a que te enseñen.
  4. . ! . , .

7. DDD


Por supuesto, a través de la práctica. Simplemente no le digas a la persona de antemano que le estás enseñando DDD, no te asustes con anticipación.

Deje que la persona venga y obtenga los rompecabezas. No le digas que es DDD, deja que lo haga. Lo hará en función de cómo entiende el sólido y todo eso. Luego, cuando entregue el trabajo, debe decir: "Querido amigo, parece funcionar, pero necesita ser rehecho", y explicarle por qué.

No fuerce a leer o aprender todo a propósito. Sea interactivo a este respecto. Entonces, una persona en 3-5 meses comenzará a comprender los principios básicos de DDD: desde el punto de vista de la implementación, desde el punto de vista de la teoría. Comenzará a comprender patrones incluso antes mediante artefactos de aproximación: mapas de contexto. Al principio, las personas no entenderán nada, pero gradualmente se cortarán, y algunos incluso leerán libros.

8. Puedo DDD - una línea sin importancia para el currículum en Rusia


Si estás en Rusia y conoces DDD, es genial. Pero está lejos del hecho de que el conocimiento de DDD en sí mismo es útil en el trabajo. Más bien, servirá como un indicador para el empleador sobre su alto nivel de desarrollo como desarrollador. Después de todo, las habilidades que adquieres al estudiar el enfoque DDD te desarrollan como programador y como diseñador (arquitecto).

Pero si está pensando en mudarse al extranjero, esa línea en el currículum puede tener un impacto positivo. En el extranjero, la comunidad DDD es mucho más grande, y el enfoque en sí es mucho más popular que el nuestro. Especialmente en Europa.

9. La relación de DDD con vello facial.


Observación: Las personas que entienden DDD usan barba. ¿Esto significa que tener barba es un requisito previo para tener éxito en DDD? ¿Qué piensas?

10. Materiales útiles sobre DDD



« ». , . , Miro, , Amazon, Microsoft, . .

:

More articles:


All Articles