{"id":16320,"date":"2025-04-29T16:39:00","date_gmt":"2025-04-29T14:39:00","guid":{"rendered":"https:\/\/festibity.com\/general\/caixa-bank-tech\/"},"modified":"2026-01-23T14:44:43","modified_gmt":"2026-01-23T12:44:43","slug":"caixa-bank-tech","status":"publish","type":"post","link":"https:\/\/festibity.com\/es\/noticies-partner\/caixa-bank-tech\/","title":{"rendered":"CAIXA BANK TECH"},"content":{"rendered":"<p><em>Art\u00edculo facilitado por Caixa Bank Tech<\/em><\/p>\n<p class=\"rtejustify\"><strong>Este art\u00edculo explora los principios fundamentales de Domain-Driven Design (DDD) y sus patrones estrat\u00e9gicos clave, como el lenguaje ubicuo y los contextos delimitados, para ayudar a alinear las aplicaciones con las necesidades del negocio, mejorar la comunicaci\u00f3n entre equipos y gestionar la complejidad en sistemas de software.<\/strong><\/p>\n<p class=\"rtejustify\">Hist\u00f3ricamente, el desarrollo de aplicaciones se hab\u00eda pensado como una actividad separada del negocio, en la que hab\u00eda una toma de requerimientos inicial para conocer necesidades y la entrega de un producto final que no siempre cumpl\u00eda con las expectativas previstas, ya que con esta forma de trabajar (en cascada) hab\u00eda poca o ninguna flexibilidad para introducir cambios durante el proyecto.<\/p>\n<p class=\"rtejustify\">Ya en 2001, con el Agile Manisfesto se empez\u00f3 a desarrollar pensando en realizar los desarrollos abrazando el cambio. Pero a\u00fan hab\u00eda un impedimento a salvar: la diferencia entre el negocio (entendido como las entidades, sus relaciones entre s\u00ed, las operaciones que deb\u00edan hacerse sobre ellas, etc.) y la forma en que este se ve\u00eda reflejado en la aplicaci\u00f3n construida.<\/p>\n<p class=\"rtejustify\">Fue a finales del a\u00f1o 2003 cuando apareci\u00f3 el libro <em>Domain-Driven Design: Tackling Complexity in the Heart of Software<\/em> escrito por Eric Evans, que ofrec\u00eda una forma distinta de hacer las cosas. El llamado \u201clibro azul del DDD\u201d no era un libro pr\u00e1ctico sobre patrones a aplicar, sino que describ\u00eda c\u00f3mo conseguir que la aplicaci\u00f3n modelase correctamente el negocio y ofrec\u00eda un conjunto de estrategias para conseguir ese objetivo.<\/p>\n<p class=\"rtejustify\">El DDD (siglas de Dominio orientado al Dominio en ingl\u00e9s) tiene especial sentido cuando afrontamos el desarrollo de aplicaciones sobre dominios de conocimiento complejos. No es siempre la mejor opci\u00f3n, ya que en dominios relativamente sencillos existen aproximaciones m\u00e1s simples que ofrecen un equilibrio entre la complejidad y el coste de construcci\u00f3n. En cambio, cuando el dominio es complejo, hacer un acercamiento de este tipo permite conseguir una <strong>mayor estabilidad de la aplicaci\u00f3n<\/strong> <strong>a los cambios<\/strong> que aparecen de forma natural al evolucionar el negocio.<\/p>\n<p class=\"rtejustify\">A continuaci\u00f3n, te damos algunas pautas para aplicar el DDD.<\/p>\n<p class=\"rtejustify\"><strong>Utilizar un lenguaje ubicuo<\/strong><\/p>\n<p class=\"rtejustify\">En muchas ocasiones, nos encontramos que una aplicaci\u00f3n tiene unas tablas, un modelo de datos y unos nombres que, al cabo de unos a\u00f1os, nadie entiende del todo lo que significan; lo que complica el entendimiento entre todas las partes implicadas.<\/p>\n<p class=\"rtejustify\">Precisamente, eso es lo que intenta evitar el uso de un lenguaje ubicuo (<em>ubiquitous language<\/em> en ingl\u00e9s).<\/p>\n<p class=\"rtejustify\">El lenguaje ubicuo es un lenguaje com\u00fan entre todos los equipos involucrados en un proyecto y tiene como objetivo evitar los malentendidos y fomentar la colaboraci\u00f3n entre desarrolladores y expertos del dominio.<\/p>\n<p class=\"rtejustify\"><strong>Un lenguaje ubicuo tiene que:<\/strong><\/p>\n<ul>\n<li class=\"rtejustify\">Estar centrado en el dominio: es decir, basarse en la forma en que los expertos del dominio (es decir, las personas que tienen un profundo conocimiento del \u00e1rea de negocio o problema que se est\u00e1 resolviendo con el software) hablan de su trabajo. No tiene sentido que los desarrolladores se expresen en otros t\u00e9rminos que pueden llevar a equivoco.<\/li>\n<li class=\"rtejustify\"><strong>Ser consistente: <\/strong>significa utilizar siempre las mismas palabras para referirse a los mismos conceptos. Si existen m\u00faltiples formas de referirse a un concepto se tiene que escoger una de ellas y utilizarla siempre de com\u00fan acuerdo.<\/li>\n<li class=\"rtejustify\"><strong>Ser preciso y claro: <\/strong>debemos evitar las ambig\u00fcedades y no utilizar el mismo nombre para referirse a conceptos distintos.<\/li>\n<li class=\"rtejustify\"><strong>Debe integrar el software y el negocio: <\/strong>cuando los t\u00e9rminos del lenguaje ubicuo se utilizan en el c\u00f3digo (en los nombres de las clases, en los m\u00e9todos o los m\u00f3dulos) conseguimos que este sea m\u00e1s f\u00e1cil de comprender por todas las partes involucradas.<\/li>\n<\/ul>\n<p class=\"rtejustify\">Con este enfoque, conseguimos que haya una forma de describir los problemas del dominio y que la soluci\u00f3n propuesta a los mismos sea comprensible por todos los equipos. Y lo mismo sucede con el c\u00f3digo. Los desarrolladores van a ser capaces de hablar con negocio en unos t\u00e9rminos comunes.<\/p>\n<p class=\"rtejustify\"><strong>Pongamos un ejemplo esclarecedor:<\/strong><\/p>\n<ul>\n<li class=\"rtejustify\">Los expertos del dominio nos explican que existen las Cuentas Bancarias y que estas tienen un Titular, un Saldo y una FechaValor para este saldo. En ellas siempre se puede Depositar un importe que se suma al Saldo y se puede Retirar un importe que se resta al Saldo siempre que este sea menor al Saldo existente. En ambos casos se actualiza la FechaValor<\/li>\n<li class=\"rtejustify\">Entonces el c\u00f3digo deber\u00eda ser algo del estilo:\n<ul>\n<li>Clase CuentaBancaria\n<ul>\n<li>Titular<\/li>\n<li>Saldo<\/li>\n<li>FechaValor<\/li>\n<\/ul>\n<\/li>\n<li>Y deber\u00eda tener m\u00e9todos de este estilo:\n<ul>\n<li>Depositar(importe, fecha)<\/li>\n<li>Retirar(importe, fecha)<\/li>\n<\/ul>\n<\/li>\n<li>Un ejemplo en pseudoc\u00f3digo ser\u00eda:\n<ul>\n<li>Depositar(importe, fecha): Saldo = Saldo + importe, FechaValor = fecha<\/li>\n<li>Retirar(importe, fecha): Si Saldo < importe LanzarError Sino Saldo = Saldo \u2013 importe, FechaValor = fecha<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p class=\"rtejustify\">Tomando como base este ejemplo, los expertos del dominio ahora podr\u00edan pedir un listado mensual con las cuentas en las que no ha habido actividad durante el \u00faltimo mes y, por su parte, el equipo de desarrollo podr\u00e1 proponer seleccionar las CuentaBancaria\u2019s en que la FechaValor sea anterior al mes en curso.<\/p>\n<p class=\"rtejustify\">De esta forma, lo que se pide y lo que se implementa estar\u00e1 perfectamente alineado y todo el mundo entender\u00e1 lo que se va a hacer y c\u00f3mo funciona.<\/p>\n<p class=\"rtejustify\"><strong>En general el lenguaje ubicuo:<\/strong><\/p>\n<ul>\n<li class=\"rtejustify\">Mejora la comunicaci\u00f3n dentro del equipo y evita malentendidos<\/li>\n<li class=\"rtejustify\">Permite alinear negocio y tecnolog\u00eda, ya que se consigue que lo implementado cumpla las necesidades reales<\/li>\n<li class=\"rtejustify\">Favorece un c\u00f3digo m\u00e1s legible, preciso y mantenible, evitando confusiones durante el desarrollo<\/li>\n<li class=\"rtejustify\">Mejora la colaboraci\u00f3n entre \u00e1reas al hacer las discusiones t\u00e9cnicas m\u00e1s accesibles para negocio<\/li>\n<\/ul>\n<p class=\"rtejustify\"><strong>Contexto delimitado<\/strong><\/p>\n<p class=\"rtejustify\">Mediante la divisi\u00f3n de nuestra aplicaci\u00f3n en distintos contextos conseguimos dividir un sistema complejo en piezas m\u00e1s aut\u00f3nomas y m\u00e1s f\u00e1cilmente mantenibles.<\/p>\n<p class=\"rtejustify\">La idea es que cada contexto tenga su propio lenguaje ubicuo y se modele el negocio para resolver una parte espec\u00edfica del problema global. En esa peque\u00f1a parcela conseguimos que el dominio tenga un significado espec\u00edfico, que sea coherente y consistente con las reglas de negocio que pueda haber en esa parte del dominio.<\/p>\n<p class=\"rtejustify\">A esos distintos contextos los llamamos contextos delimitados (o <em>bounded contexts<\/em> en ingl\u00e9s).<\/p>\n<p class=\"rtejustify\">Una de las fortalezas m\u00e1s importantes de los contextos acotados es que tienen unos l\u00edmites bien definidos que permiten aislarse del resto de la aplicaci\u00f3n y que sus cambios no afecten al resto.<\/p>\n<p class=\"rtejustify\">Asimismo, existen patrones con los que favorecer la colaboraci\u00f3n entre distintos contextos acotados manteniendo el aislamiento entre ellos (uso de APIs, uso de eventos, uso de capas de anticorrupci\u00f3n, etc.).<\/p>\n<p class=\"rtejustify\">Un ejemplo: dentro de una entidad bancaria puede existir el contexto de las cuentas bancarias y el contexto de los pr\u00e9stamos y ambos tienen que poder evolucionar de forma independiente a pesar de poder tener relaci\u00f3n.<\/p>\n<p class=\"rtejustify\">Adem\u00e1s, el concepto de contexto delimitado se puede explotar tanto como sea necesario para reducir la complejidad haciendo que dentro de un mismo contexto haya subcontextos m\u00e1s peque\u00f1os que igualmente est\u00e1n cohesionados y en los que se puede implementar una funcionalidad independientemente del resto del contexto.<\/p>\n<p class=\"rtejustify\">A nivel pr\u00e1ctico, para identificar un contexto delimitado dentro de nuestro dominio tenemos que buscar \u00e1reas en que se utilice un conjunto \u00fanico de t\u00e9rminos (el lenguaje ubicuo en ese contexto) o reglas \u00fanicas, \u00e1reas que tengan unos requisitos funcionales muy diferenciados del resto o \u00e1reas que representen una separaci\u00f3n natural del flujo de trabajo o los procesos de negocio.<\/p>\n<p class=\"rtejustify\">Los contextos delimitados son de vital importancia para impedir que nuestro sistema se convierta en un monolito al dividir de forma clara los distintos modelos que existen dentro del negocio y permitir posibilidades t\u00e9cnicas como el uso de arquitecturas distribuidas.<\/p>\n<p class=\"rtejustify\"><strong>Mapa de contextos<\/strong><\/p>\n<p class=\"rtejustify\">Como hemos comentado al separar nuestro sistema en distintos contextos delimitados podemos terminar con muchos contextos peque\u00f1os y necesitamos tener clara la forma en que van a interactuar entre s\u00ed.<\/p>\n<p class=\"rtejustify\">Para ello usamos el mapa de contextos (o <em>context map<\/em> en ingl\u00e9s) que es una representaci\u00f3n visual de los contextos delimitados y como interaccionan ya sea de forma jer\u00e1rquica o mediante colaboraci\u00f3n.<\/p>\n<p class=\"rtejustify\">Si existe una relaci\u00f3n jer\u00e1rquica entre contextos delimitados, el contexto dominante impone sus t\u00e9rminos y los contextos subordinados suelen adaptarse.<\/p>\n<p class=\"rtejustify\">En este tipo de relaci\u00f3n los patrones de integraci\u00f3n m\u00e1s comunes, en este caso, son el patr\u00f3n Conformista, el patr\u00f3n Capa de Anticorrupci\u00f3n, el patr\u00f3n N\u00facleo Compartido o el patr\u00f3n Cliente-Proveedor.<\/p>\n<p class=\"rtejustify\">Hay ocasiones en que los contextos delimitados colaboran entre s\u00ed en plena igualdad de condiciones entonces se tienen que usar otros patrones. Estos son el patr\u00f3n Asociaci\u00f3n, el patr\u00f3n N\u00facleo Compartido (en efecto, este patr\u00f3n se puede usar tanto en interacci\u00f3n jer\u00e1rquica como en interacci\u00f3n colaborativa), el patr\u00f3n Lenguaje Publicado y el patr\u00f3n V\u00edas Separadas.<\/p>\n<p class=\"rtejustify\"><strong>Como escoger entre este conjunto de patrones forma parte del arte de hacer un dise\u00f1o guiado por el dominio, pero aqu\u00ed tienes unas recomendaciones:<\/strong><\/p>\n<ul>\n<li class=\"rtejustify\">Si un contexto depende completamente de otro para funcionar correctamente es m\u00e1s conveniente usar un patr\u00f3n jer\u00e1rquico. Por ejemplo, contexto de precios est\u00e1 subordinado a contexto de productos.<\/li>\n<li class=\"rtejustify\">Si ambos contextos son aut\u00f3nomos y pueden funcionar sin que uno domine al otro es m\u00e1s conveniente usar un patr\u00f3n colaborativo. Por ejemplo, contexto de pedidos y contexto de env\u00edos, aunque est\u00e9n relacionados pueden colaborar independientemente.<\/li>\n<li class=\"rtejustify\">Si un contexto siempre ejecuta acciones definidas por otro estamos ante una relaci\u00f3n jer\u00e1rquica. Pero si los dominios solamente necesitan compartir informaci\u00f3n estamos ante una relaci\u00f3n de colaboraci\u00f3n.<\/li>\n<li class=\"rtejustify\">Cuando usamos un patr\u00f3n jer\u00e1rquico si el dominio subordinado puede adoptar el modelo del dominio dominante lo m\u00e1s conveniente es utilizar el patr\u00f3n Conformista. Si por el contrario queremos que el dominio subordinado mantenga su modelo y sus reglas por consistencia interna deberemos usar un patr\u00f3n como Capa de Anticorrupci\u00f3n o N\u00facleo Compartido.<\/li>\n<li class=\"rtejustify\">Si un dominio tiene influencia en c\u00f3mo se dise\u00f1a otro dominio es mejor utilizar patrones de colaboraci\u00f3n como el Asociaci\u00f3n.<\/li>\n<\/ul>\n<p class=\"rtejustify\">Para realizar un mapa de contextos se suelen usar rect\u00e1ngulos o cajas para los contextos y flechas para indicar las relaciones entre ellos. Estas flechas pueden ser unidireccionales si la relaci\u00f3n es jer\u00e1rquica y bidireccionales si la relaci\u00f3n es colaborativa. En estas flechas se suele indicar el patr\u00f3n que queremos aplicar (Conformista, Asociaci\u00f3n, etc.). Tambi\u00e9n es com\u00fan, si se tiene claro en el momento de realizar el mapa, el mecanismo que se utiliza para esa comunicaci\u00f3n (API, evento, integraci\u00f3n en c\u00f3digo, etc.).<\/p>\n<p class=\"rtejustify\"><strong>A continuaci\u00f3n, describiremos brevemente los principales patrones a modo informativo.<\/strong><\/p>\n<p class=\"rtejustify\"><strong>> Patr\u00f3n Conformista<\/strong><\/p>\n<p class=\"rtejustify\">Este patr\u00f3n (<em>Conformist<\/em> en ingl\u00e9s) es jer\u00e1rquico y consiste en que el contexto subordinado acepta completamente el modelo y las reglas del contexto dominante. No intenta modificarlo en absoluto o ni siquiera adaptarse para mantener un modelo propio. La ventaja que ofrece es que es de f\u00e1cil integraci\u00f3n, pero reduce la autonom\u00eda del contexto y puede estar afectado por un cambio del contexto dominante.<\/p>\n<p class=\"rtejustify\"><strong>> Patr\u00f3n Capa de Anticorrupci\u00f3n<\/strong><\/p>\n<p class=\"rtejustify\">Este patr\u00f3n (<em>Anticorruption Layer<\/em> en ingl\u00e9s) es jer\u00e1rquico y consiste en proteger el modelo propio respecto al modelo del contexto dominante usando una capa de traducci\u00f3n que act\u00faa como mediador. La ventaja es que protege al contexto de los cambios que se puedan producir en el contexto dominante y permite mantener un modelo independiente, pero requiere mayor esfuerzo de implementaci\u00f3n y puede introducir problemas de rendimiento por tener que introducir la capa de traducci\u00f3n.<\/p>\n<p class=\"rtejustify\"><strong>> Patr\u00f3n N\u00facleo Compartido<\/strong><\/p>\n<p class=\"rtejustify\">Este patr\u00f3n (<em>Shared Kernel<\/em> en ingl\u00e9s) se puede considerar jer\u00e1rquico o colaborativo. Se fundamente en tener una parte del modelo que se comparte entre ambos contextos, pero poder evolucionar independientemente en el resto del modelo. Su ventaja es que reduce la duplicaci\u00f3n de los conceptos comunes y permite consistencia de los datos compartidos, pero los cambios en el n\u00facleo compartido impactan a los dos dominios y requiere una alta colaboraci\u00f3n entre los equipos de ambos dominios.<\/p>\n<p class=\"rtejustify\"><strong>> Patr\u00f3n Cliente-Proveedor<\/strong><\/p>\n<p class=\"rtejustify\">Este patr\u00f3n (<em>Customer-Supplier<\/em> en ingl\u00e9s) es jer\u00e1rquico y hace que el contexto subordinado act\u00fae como cliente y el contexto dominante act\u00fae como proveedor. En este sentido, el subordinado influye en las decisiones del dominante ya que consume datos o funcionalidades adaptadas a sus necesidades. Su ventaja es que facilita la colaboraci\u00f3n y est\u00e1 bien adaptada a las necesidades del subordinado, pero requiere una coordinaci\u00f3n continua y activa y si el dominante tiene demasiados subordinados puede generar trabajo adicional.<\/p>\n<p class=\"rtejustify\"><strong>> Patr\u00f3n Asociaci\u00f3n<\/strong><\/p>\n<p class=\"rtejustify\">Este patr\u00f3n (<em>Partnership<\/em> en ingl\u00e9s) es colaborativo y conveniente cuando ambos contextos trabajan estrechamente como socios igualitarios para lograr un objetivo com\u00fan. La coordinaci\u00f3n entre ambos contextos es continua para garantizar la compatibilidad mutua. Su ventaja es que permite una evoluci\u00f3n coordinada de ambos contextos y la integraci\u00f3n es la justa y necesaria, la desventaja es, como hemos indicado, la coordinaci\u00f3n continua y que si ambos equipos no tienen el mismo ritmo de trabajo puede producir problemas.<\/p>\n<p class=\"rtejustify\"><strong>> Patr\u00f3n Lenguaje Publicado<\/strong><\/p>\n<p class=\"rtejustify\">Este patr\u00f3n (<em>Published Language<\/em> en ingl\u00e9s) es colaborativo y consiste en establecer un protocolo o forma de interaccionar para publicar su modelo de forma clara y consistente a otros contextos. Permite f\u00e1cilmente relaciones con diversos contextos y no solo uno. El ejemplo t\u00e9cnico de este patr\u00f3n es la publicaci\u00f3n de APIs con mensajer\u00edas claramente definidas mediante OpenAPI. Sus ventajas son una alta claridad en la integraci\u00f3n y que permite interaccionar con m\u00faltiples contextos, pero puede requerir cambios en los consumidores cuando se cambia el lenguaje publicado y requiere que se mantenga actualizado y documentado.<\/p>\n<p class=\"rtejustify\"><strong>> Patr\u00f3n V\u00edas Separadas<\/strong><\/p>\n<p class=\"rtejustify\">Este patr\u00f3n (<em>Separate Ways<\/em> en ingl\u00e9s) es colaborativo y es conveniente cuando dos contextos no quieren colaborar de ninguna forma y poder resolver sus problemas de forma independiente. Este patr\u00f3n suele generar duplicidad de datos o de l\u00f3gica de negocio, pero fomenta la autonom\u00eda y la independencia y reduce el riesgo de que un contexto afecte al otro.<\/p>\n<p class=\"rtejustify\"><strong>Conclusiones<\/strong><\/p>\n<p class=\"rtejustify\">El <em>Domain-Driven Design<\/em> ofrece una estrategia para abordar la complejidad de un sistema de aplicaciones.<\/p>\n<p class=\"rtejustify\">Los contextos delimitados permiten dividir el dominio en partes manejables y los patrones estrat\u00e9gicos facilitan formas de integrarse claras y reconocibles.<\/p>\n<p class=\"rtejustify\">Adoptando estas pr\u00e1cticas se promueve la autonom\u00eda de los equipos y la flexibilidad en las aplicaciones.<\/p>\n<p class=\"rtejustify\">Pero, sobre todo, fomenta la comunicaci\u00f3n clara entre los equipos y que el modelo del dominio evolucione junto con las necesidades del negocio.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Art\u00edculo facilitado por Caixa Bank Tech Este art\u00edculo explora los principios fundamentales de Domain-Driven Design (DDD) y sus patrones estrat\u00e9gicos clave, como el lenguaje ubicuo y los contextos delimitados, para ayudar a alinear las aplicaciones con las necesidades del negocio, mejorar la comunicaci\u00f3n entre equipos y gestionar la complejidad en sistemas de software. Hist\u00f3ricamente, el [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":19607,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":"","_members_access_role":[],"_members_access_error":""},"categories":[35],"tags":[],"class_list":["post-16320","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-noticies-partner"],"acf":[],"_links":{"self":[{"href":"https:\/\/festibity.com\/es\/wp-json\/wp\/v2\/posts\/16320","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/festibity.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/festibity.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/festibity.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/festibity.com\/es\/wp-json\/wp\/v2\/comments?post=16320"}],"version-history":[{"count":1,"href":"https:\/\/festibity.com\/es\/wp-json\/wp\/v2\/posts\/16320\/revisions"}],"predecessor-version":[{"id":17658,"href":"https:\/\/festibity.com\/es\/wp-json\/wp\/v2\/posts\/16320\/revisions\/17658"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/festibity.com\/es\/wp-json\/wp\/v2\/media\/19607"}],"wp:attachment":[{"href":"https:\/\/festibity.com\/es\/wp-json\/wp\/v2\/media?parent=16320"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/festibity.com\/es\/wp-json\/wp\/v2\/categories?post=16320"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/festibity.com\/es\/wp-json\/wp\/v2\/tags?post=16320"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}