Aprendizaje del Diseño Orientado al Dominio

Prefacio

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Recuerdo vívidamente el día que empecé mi primer trabajo real de ingeniería de software. Estaba extasiado y aterrorizado a la vez. Después de piratear software para empresas locales durante mis años de instituto, estaba ansioso por convertirme en un "programador de verdad" y escribir algo de código para una de las mayores empresas de subcontratación del país.

En mis primeros días allí, mis nuevos compañeros me enseñaban las cuerdas. Tras configurar el correo electrónico corporativo y repasar el sistema de control horario, pasamos por fin a lo interesante: el estilo y las normas de codificación de la empresa. Me dijeron que "aquí siempre escribimos código bien diseñado y utilizamos la arquitectura en capas ". Repasamos la definición de cada una de las tres capas -acceso a datos, lógica empresarial y capas de presentación- y luego hablamos de las tecnologías y los marcos para abordar las necesidades de las capas. Por aquel entonces, la solución aceptada para almacenar datos era Microsoft SQL Server 2000, y se integraba utilizando ADO.NET en la capa de acceso a datos. La capa de presentación se basaba en WinForms para aplicaciones de escritorio o ASP.NET WebForms para la web. Dedicamos bastante tiempo a estas dos capas, así que me extrañó que no se prestara atención a la capa de lógica empresarial:

"¿Pero qué pasa con la capa de lógica empresarial?"

"Eso es sencillo. Aquí es donde implementas la lógica empresarial".

"Pero, ¿qué es la lógica empresarial?"

"Oh, la lógica empresarial son todos los bucles y sentencias 'if-else' que necesitas para implementar los requisitos".

Ese día comencé mi viaje para averiguar qué es exactamente la lógica empresarial y cómo demonios debe implementarse en un código bien diseñado. Me llevó más de tres años encontrar finalmente la respuesta.

La respuesta estaba en el libro seminal de Eric Evans, Domain-Driven Design: Afrontar la complejidad en el corazón del software. Resultó que no me equivocaba. La lógica empresarial es realmente importante: ¡es el corazón del software! Por desgracia, sin embargo, tardé otros tres años en comprender la sabiduría que Eric compartía. El libro es muy avanzado, y el hecho de que el inglés sea mi tercera lengua no ayudó.

Con el tiempo, sin embargo, todo encajó, e hice las paces con la metodología del diseño dirigido por dominios (DDD). Aprendí los principios y patrones del DDD, las complejidades del modelado y la implementación de la lógica empresarial, y cómo abordar la complejidad en el corazón del software que estaba construyendo. A pesar de los obstáculos, definitivamente mereció la pena. Adentrarme en el diseño dirigido por dominios fue para mí una experiencia que cambió mi carrera.

Por qué escribí este libro

En los últimos 10 años, he presentado el diseño orientado a dominios a mis colegas de distintas empresas, he impartido clases presenciales y he dictado cursos en línea. La perspectiva docente no sólo me ayudó a profundizar en mis conocimientos, sino que también me permitió optimizar la forma en que explico los principios y patrones del diseño orientado a dominios.

Como suele ocurrir, enseñar es incluso más difícil que aprender. Soy un gran admirador del trabajo y las enseñanzas de Eliyahu M. Goldratt. Eliyahu solía decir que incluso los sistemas más complejos son intrínsecamente sencillos cuando se ven desde el ángulo correcto. Durante mis años de enseñanza de DDD, buscaba un modelo de la metodología que descubriera la simplicidad inherente al diseño dirigido por dominios.

Este libro es el resultado de mis esfuerzos. Su objetivo es democratizar el diseño dirigido por dominios; hacerlo más fácil de entender y más accesible de emplear. Creo que la metodología DDD es absolutamente inestimable, especialmente a la hora de diseñar sistemas de software modernos. Este libro te dará las herramientas suficientes para empezar a aplicar el diseño orientado a dominios en tu trabajo diario.

Quién debería leer este libro

Creo que el conocimiento de los principios y patrones del diseño dirigido por dominios será útil para los ingenieros de software de todos los niveles: junior, senior, personal y principal. DDD no sólo proporciona herramientas y técnicas para modelar e implementar eficazmente el software, sino que también ilumina un aspecto de la ingeniería de software que a menudo se pasa por alto: el contexto. Equipado con el conocimiento del problema empresarial del sistema, serás mucho más eficaz a la hora de elegir la solución adecuada. Una solución que no esté infra o sobredimensionada, sino que responda a las necesidades y objetivos empresariales.

El diseño dirigido por dominios es aún más importante para los arquitectos de software, y más aún para los aspirantes a arquitectos de software. Sus herramientas de decisión estratégica de diseño te ayudarán a descomponer un gran sistema en componentes -servicios, microservicios o subsistemas- y adiseñar cómo se integran los componentes entre sí para formar un sistema.

En definitiva, en este libro hablaremos no sólo de cómo diseñar software, sino también de cómo coevolucionar el diseño con los cambios en su contexto empresarial. Ese aspecto crucial de la ingeniería de software te ayudará a mantener el diseño del sistema "en forma" a lo largo del tiempo y a evitar que se degrade hasta convertirse en una gran bola de barro.

Navegar por el Libro

Este libro se divide en cuatro partes: diseño estratégico, diseño táctico, DDD en la práctica y relaciones de DDD con otras metodologías y patrones. En la Parte I, cubrimos las herramientas y técnicas para tomar decisiones de diseño de software a gran escala. En la Parte II, nos centramos en el código: las distintas formas de implementar la lógica empresarial de un sistema. La Parte III trata de las técnicas y estrategias para aplicar el DDD en proyectos de la vida real. La Parte IV continúa el debate sobre el diseño dirigido por dominios, pero esta vez en el contexto de otras metodologías y patrones.

He aquí un breve resumen de lo que encontrarás en cada capítulo:

• El Capítulo 1 establece el contexto de un proyecto de ingeniería de software: el ámbito empresarial, sus objetivos y cómo se pretende que el software los respalde.

• El capítulo 2 introduce la noción de un "lenguaje ubicuo": la práctica del diseño orientado al dominio para una comunicación y un intercambio de conocimientos eficaces.

• El capítulo 3 trata de cómo abordar la complejidad de los dominios empresariales y diseñar los componentes arquitectónicos de alto nivel del sistema: los contextos delimitados.

• El capítulo 4 explora los distintos patrones de organización de la comunicación y la integración entre los contextos delimitados.

• El Capítulo 5 inicia el debate sobre los patrones de implementación de la lógica empresarial con dos patrones que abordan los casos de lógica empresarial simple.

• El capítulo 6 avanza de la lógica empresarial simple a la compleja e introduce el patrón de modelo de dominio para abordar su complejidad.

• El Capítulo 7 añade la perspectiva del tiempo e introduce una forma aún más avanzada de modelar e implementar la lógica empresarial: el modelo de dominio basado en eventos.

• El capítulo 8 cambia el enfoque a un nivel superior y describe tres patrones arquitectónicos para estructurar componentes.

• El Capítulo 9 proporciona los patrones necesarios para orquestar el trabajo de los componentes del sistema.

• El Capítulo 10 reúne los patrones tratados en los capítulos anteriores en una serie de sencillas reglas generales que agilizan el proceso de toma de decisiones de diseño.

• El Capítulo 11 explora el diseño de software desde la perspectiva del tiempo y cómo se supone que debe cambiar y evolucionar a lo largo de su vida útil.

• El capítulo 12 presenta el EventStorming: un taller de baja tecnología para compartir conocimientos de forma eficaz, construir un entendimiento compartido y diseñar software.

• El Capítulo 13 aborda las dificultades a las que puedes enfrentarte al introducir el diseño basado en dominios en los proyectos de zonas industriales abandonadas.

• El capítulo 14 trata de la relación entre el estilo arquitectónico de microservicios y el diseño dirigido por dominios: en qué se diferencian y en qué se complementan.

• El Capítulo 15 explora los patrones y herramientas de diseño basados en dominios en el contexto de la arquitectura basada en eventos.

• El capítulo 16 traslada el debate de los sistemas operativos a los sistemas analíticos de gestión de datos y analiza la interacción entre el diseño basado en dominios y la arquitectura de malla de datos.

Todos estos capítulos terminan con una serie de preguntas de ejercicio para reforzar el aprendizaje. Algunas de las preguntas utilizan la empresa ficticia "WolfDesk" para demostrar los distintos aspectos del diseño basado en dominios. Lee la siguiente descripción de WolfDesk y vuelve a ella cuando respondas a las preguntas de los ejercicios pertinentes.

Ejemplo de dominio: WolfDesk

WolfDesk proporciona un sistema de gestión de tickets de help desk como servicio. Si tu empresa de nueva creación necesita dar soporte a sus clientes, con la solución de WolfDesk podrás ponerte en marcha en muy poco tiempo.

WolfDesk utiliza un modelo de pago diferente al de sus competidores. En lugar de cobrar una cuota por usuario, permite a los arrendatarios configurar tantos usuarios como necesiten, y a los arrendatarios se les cobra por el número de tickets de soporte abiertos por periodo de tarificación. No hay cuota mínima, y hay descuentos automáticos por volumen para determinados umbrales de tickets mensuales: 10% por abrir más de 500 tickets, 20% por abrir más de 750 tickets y 30% por abrir más de 1.000 tickets al mes.

Para evitar que los inquilinos abusen del modelo de negocio, el algoritmo del ciclo de vida de los tickets de WolfDesk garantiza que los tickets inactivos se cierren automáticamente, animando a los clientes a abrir nuevos tickets cuando necesiten más asistencia. Además, WolfDesk implementa un sistema de detección de fraudes que analiza los mensajes y detecta casos de temas no relacionados que se discuten en el mismo ticket.

Para ayudar a sus inquilinos a agilizar el trabajo relacionado con el soporte, WolfDesk ha implementado una función de "piloto automático de soporte". El piloto automático analiza los nuevos tickets e intenta encontrar automáticamente una solución adecuada a partir del historial de tickets del inquilino. La funcionalidad permite reducir aún más la vida útil de los tickets, animando a los clientes a abrir nuevos tickets para más preguntas.

WolfDesk incorpora todas las normas y medidas de seguridad para autenticar y autorizar a los usuarios de sus inquilinos, y también permite a éstos configurar un inicio de sesión único (SSO) con sus sistemas existentes de gestión de usuarios.

La interfaz de administración permite a los arrendatarios configurar los valores posibles para las categorías de los tickets, así como una lista de los productos del arrendatario que admite.

Para poder dirigir las nuevas incidencias a los agentes de soporte del inquilino sólo durante su horario laboral, WolfDesk permite introducir el horario de turnos de cada agente.

Como WolfDesk ofrece su servicio sin una cuota mínima, tiene que optimizar su infraestructura de forma que se minimicen los costes de incorporación de un nuevo inquilino. Para ello, WolfDesk aprovecha la informática sin servidor, que le permite escalar elásticamente sus recursos informáticos en función de las operaciones de los tickets activos.

Convenciones utilizadas en este libro

En este libro se utilizan las siguientes convenciones tipográficas:

Cursiva

Indica nuevos términos, URL, direcciones de correo electrónico, nombres de archivo y extensiones de archivo.

Constant width

Se utiliza en los listados de programas, así como dentro de los párrafos para referirse a elementos del programa como nombres de variables o funciones, bases de datos, tipos de datos, variables de entorno, sentencias y palabras clave.

Nota

Este elemento significa una nota general.

Utilizar ejemplos de código

El material complementario (ejemplos de código, ejercicios, etc.) se puede descargar de en https://learning-ddd.com.

Todos los ejemplos de código presentados en el libro están implementados en el lenguaje C#. En general, los ejemplos de código que verás en los capítulos son extractos que demuestran los conceptos tratados.

Por supuesto, los conceptos y técnicas tratados en el libro no se limitan al lenguaje C# ni al enfoque de programación orientada a objetos. Todo es relevante para otros lenguajes y otros paradigmas de programación. Por ello, no dudes en implementar los ejemplos del libro en tu lenguaje favorito y compartirlos conmigo. Estaré encantado de añadirlos al sitio web del libro.

Si tienes una pregunta técnica o un problema al utilizar los ejemplos de código, envía un correo electrónico a [e-mail].

Este libro está aquí para ayudarte a hacer tu trabajo. En general, si se ofrece código de ejemplo con este libro, puedes utilizarlo en tus programas y documentación. No es necesario que te pongas en contacto con nosotros para pedirnos permiso, a menos que estés reproduciendo una parte importante del código. Por ejemplo, escribir un programa que utilice varios trozos de código de este libro no requiere permiso. Vender o distribuir ejemplos de los libros de O'Reilly sí requiere permiso. Responder a una pregunta citando este libro y el código de ejemplo no requiere permiso. Incorporar una cantidad significativa de código de ejemplo de este libro en la documentación de tu producto sí requiere permiso.

Agradecemos la atribución, pero en general no la exigimos. Una atribución suele incluir el título, el autor, la editorial y el ISBN. Por ejemplo "Learning Domain-Driven Design por Vlad Khononov (O'Reilly). Copyright 2022 Vladislav Khononov, 978-1-098-10013-1".

Si crees que el uso que haces de los ejemplos de código no se ajusta al uso legítimo o al permiso concedido anteriormente, no dudes en ponerte en contacto con nosotros en [e-mail].

Aprendizaje en línea O'Reilly

Nota

Durante más de 40 años, O'Reilly Media ha proporcionado formación tecnológica y empresarial, conocimientos y perspectivas para ayudar a las empresas a alcanzar el éxito.

Nuestra red única de expertos e innovadores comparten sus conocimientos y experiencia a través de libros, artículos y nuestra plataforma de aprendizaje online. La plataforma de aprendizaje en línea de O'Reilly te ofrece acceso bajo demanda a cursos de formación en directo, rutas de aprendizaje en profundidad, entornos de codificación interactivos y una amplia colección de textos y vídeos de O'Reilly y de más de 200 editoriales. Para más información, visita http://oreilly.com.

Cómo contactar con nosotros

Dirige tus comentarios y preguntas sobre este libro a la editorial:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Norte
• Sebastopol, CA 95472
• 800-889-8969 (en Estados Unidos o Canadá)
• 707-827-7019 (internacional o local)
• 707-829-0104 (fax)
• [e-mail]
• https://www.oreilly.com/about/contact.html

Tenemos una página web para este libro, donde se enumeran erratas, ejemplos y cualquier información adicional. Puedes acceder a esta página en https://oreil.ly/lddd.

Para obtener noticias e información sobre nuestros libros y cursos, visita https://oreilly.com.

Encuéntranos en LinkedIn: https://linkedin.com/company/oreilly-media

Míranos en YouTube: https://youtube.com/oreillymedia

Agradecimientos

Originalmente, este libro se titulaba "¿Qué es el diseño basado en dominios?" y se publicó como informe en 2019. Aprender Diseño Orientado a Dominios no habría visto la luz sin el informe, y me veo obligado a dar las gracias a quienes hicieron posible "¿Qué es el Diseño Orientado a Dominios? Chris Guzikowski, Ryan Shaw y Alicia Young.¹

Este libro tampoco habría sido posible sin la Directora de Contenidos y Jefa de Talentos de Diversidad de O'Reilly, Melissa Duffield, que defendió el proyecto y lo hizo realidad. ¡Gracias, Melissa, por toda tu ayuda!

Jill Leonard fue la editora de desarrollo del libro, directora del proyecto y entrenadora principal. No se puede exagerar el papel de Jill en este trabajo. Jill, ¡muchas gracias por todo tu duro trabajo y tu ayuda! Gracias adicionales por mantenerme motivada, incluso cuando consideré la posibilidad de cambiarme el nombre y esconderme en un país extranjero.

Un enorme agradecimiento al equipo de producción por hacer que el libro no sólo se pueda escribir, sino también leer: Kristen Brown, Audrey Doyle, Kate Dullea, Robert Romano y Katherine Tozer. En realidad, quiero dar las gracias a todo el equipo de O'Reilly por el gran trabajo que hacéis. ¡Es un sueño hecho realidad trabajar con vosotros!

Gracias a todas las personas a las que entrevisté y consulté: Zsofia Herendi, Scott Hirleman, Trond Hjorteland, Mark Lisker, Chris Richardson, Vaughn Vernon e Ivan Zakrevsky. ¡Gracias por vuestra sabiduría y por estar ahí cuando necesité ayuda!

Un agradecimiento especial al equipo de revisores que leyeron los primeros borradores y me ayudaron a dar forma al libro final: Julie Lerman, Ruth Malan, Diana Montalion, Andrew Padilla, Rodion Promyshlennikov, Viktor Pshenitsyn, Alexei Torunov, Nick Tune, Vasiliy Vasilyuk y Rebecca Wirfs-Brock. Vuestro apoyo, comentarios y críticas han sido de gran ayuda. ¡Gracias a todos!

También quiero dar las gracias a Kenny Baas-Schwegler, Alberto Brandolini, Eric Evans, Marco Heimeshoff, Paul Rayner, Mathias Verraes y al resto de la increíble comunidad de diseño basado en dominios. Vosotros sabéis quiénes sois. Sois mis maestros y mentores. Gracias por compartir vuestros conocimientos en las redes sociales, los blogs y las conferencias.

Estoy muy en deuda con mi querida esposa, Vera, por apoyarme siempre en mis locos proyectos e intentar protegerme de las cosas que podrían distraerme de escribir. Prometo desordenar por fin el sótano. ¡Pronto lo haré!

Por último, quiero dedicar este libro a nuestra querida Galina Ivanovna Tyumentseva, que tanto me apoyó en este proyecto y a quien tristemente perdimos durante la redacción de este libro. Siempre te recordaremos.

#AdoptaNoCompras

¹ Siempre que menciono a un grupo de personas, la lista está en orden alfabético por apellido.