Domain Driven Design (DDD) en una arquitectura de servicios bancarios con BIAN (Banking Industry Architecture Network).

0
576
Vista de las áreas de negocio en el BIAN Service Domain Landscape versión 12.0, con dominios de servicio para datos de referencia, ventas y servicio, y operaciones y ejecución
Estructura de áreas de negocio en el BIAN Service Domain Landscape V12.0

Banking Industry Architecture Network (BIAN) proporciona un marco de referencia para la definición e implementación de servicios bancarios que promueven la modularización e interoperabilidad y, en este tutorial, vamos a llevar a cabo una introducción al framework analizando qué paralelismos se pueden establecer entre los conceptos de BIAN y los de DDD (Domain Driven Design) para llevar a cabo una implementación de esos servicios bancarios orientados a la delimitación de contextos de dominio.

Contenido.

1. Introducción.

Banking Industry Architecture Network (BIAN) es un marco de referencia, específico para el sector financiero, que proporciona un modelo de arquitectura basado en las capacidades de negocio y los servicios TI necesarios para operar un banco.

BIAN es también la organización, detrás del marco de referencia, que busca transformar la industria bancaria mediante la estandarización y la simplificación de la arquitectura de servicios. Fundada en 2008, reúne a un amplio grupo de instituciones financieras, empresas de tecnología y consultoras que colaboran para desarrollar un marco común que facilite la interoperabilidad y la innovación en los servicios bancarios.

Los miembros de BIAN trabajan juntos para definir y estandarizar servicios que promuevan la eficiencia y la flexibilidad, permitiendo a las organizaciones adaptarse a un entorno financiero en constante cambio.

En definitiva, BIAN es, al sector financiero, lo que otros marcos de referencia lo son a otros sectores, como:

  • Arts para el sector retail,
  • Moda para el sector telco, junto con el catálogo de oda, o
  • hl7 para el sector sanitario

Son redes que se enfocan en crear ecosistemas donde se puedan compartir mejores prácticas y adoptar soluciones tecnológicas avanzadas, beneficiándose de la experiencia colectiva de la industria.

2. Entorno.

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 16′ (Apple M1 Pro, 32GB DDR4).
  • Sistema Operativo: Mac OS Sonoma 14.6.1
  • BIAN 12.0.0

3. Conceptos fundamentales de BIAN.

Domain Service Landscape

BIAN Domain Service Landscape es la representación gráfica que organiza los distintos servicios y capacidades de un banco en función de dominios y áreas de negocio. Permite a las instituciones financieras tener una vista clara de los procesos y cómo interactúan. Está estructurado en tres capas principales:

  • Dominios de servicio (Service Domains)
  • Capacidades de negocio (Business Capabilities)
  • Interacciones de negocio (Business Scenarios)

El Domain Service Landscape facilita la modularización y estandarización, proporcionando una visión clara de cómo se pueden estructurar los servicios TI en una institución bancaria.

Value Chain View vs. Matrix View

En BIAN, dentro del Domain Service Landscape existen dos vistas que ayudan a abordar diferentes perspectivas del modelo bancario:

  • Value Chain View: ofrece una vista de alto nivel de las actividades clave del negocio, organizada en cadenas de valor. Es útil para entender cómo los diferentes procesos generan valor dentro del banco, y permite una evaluación del flujo de servicios a través de toda la organización.
  • Matrix View: esta vista organiza las capacidades de negocio de manera más detallada, cruzando áreas de negocio y dominios de servicio. Proporciona una perspectiva más técnica, ideal para alinear los servicios específicos con los dominios funcionales. Es particularmente útil para los arquitectos de TI, ya que detalla cómo los servicios y capacidades interactúan dentro de un banco; es por ello que nos centraremos en esta vista.

Business Area

Dentro de la vista de Matrix View, una Business Area representa una agrupación de capacidades funcionales que son fundamentales para las operaciones generales de un banco. Se sitúa en la parte superior del Landscape y actúa como un contenedor de los diferentes Business Domains, que a su vez agrupan los Service Domains.

Business Domain

Un Business Domain dentro de BIAN es una agrupación de capacidades de negocio que representan una función mayor dentro del banco, como la gestión de pagos o la administración de préstamos. Cada dominio agrupa capacidades de alto nivel que permiten al banco operar en áreas específicas, y es la base sobre la cual se pueden construir los servicios más detallados.

Service Domain

Service Domain es el nivel más granular del BIAN Landscape, donde se definen servicios específicos que soportan una capacidad de negocio. Cada Service Domain tiene interfaces claramente definidas que permiten su interacción con otros dominios.

 

Puedes consultar el meta-modelo de BIAN aquí.

Un Service Domain se estructura en varios componentes, cada uno con un rol específico dentro de la arquitectura bancaria. Aquí tienes una descripción más detallada de los elementos clave:

Service Groups

Cada Service Domain incluye uno o varios Service Groups. Los Service Groups representan agrupaciones lógicas de funcionalidades relacionadas que un Service Domain ofrece. Pueden considerarse como «categorías» dentro de un dominio, que organizan los servicios en subconjuntos manejables. Estos grupos ayudan a organizar mejor las operaciones dentro de un Service Domain, facilitando la modularización de los servicios ofrecidos.


https://bian.org/servicelandscape-12-0-0/object_20.html?object=243671
https://bian.org/servicelandscape-12-0-0/object_17.html?object=91540

Service Operations

Dentro de cada Service Group, encontramos las Service Operations, que son las unidades funcionales más pequeñas de un Service Domain. Las Service Operations son las operaciones específicas que realiza el dominio en respuesta a una solicitud o para procesar una tarea. Estas pueden incluir acciones como:

  • Solicitar datos,
  • Procesar una transacción,
  • Generar un reporte.

Cada Service Operation está definida con precisión para ser invocable a través de interfaces bien definidas, facilitando la interoperabilidad y estandarización entre diferentes Service Domains.

https://bian.org/servicelandscape-12-0-0/object_12.html?object=29214

Control Record y Behavior Qualifier

Los conceptos de Control Record y Behavior Qualifier son términos se utilizan para definir cómo se estructura y gestiona la información empresarial dentro de un Service Domain.

https://bian.org/servicelandscape-12-0-0/views/view_51810.html

Control Record representa la colección de información que gestiona un Service Domain. Es fundamental para ejecutar un patrón funcional sobre un activo específico, asegurando que los datos relevantes se manejen adecuadamente a lo largo del ciclo de vida del activo.

https://bian.org/servicelandscape-12-0-0/views/view_36677.html

Behavior Qualifier es un desglose adicional del Control Record, que refina el alcance de la información al representar contextos o objetivos más específicos. Ayuda a dividir el comportamiento de un Service Domain en partes más estrechas y manejables.

Ambos conceptos juegan un papel crítico en la definición y gestión de servicios empresariales, asegurando consistencia en cómo se operan los servicios y se procesa la información en las diferentes funciones bancarias.

4. Conceptos claves de DDD

Domain Driven Design es una metodología de desarrollo de software que se centra en entender y modelar el dominio de un negocio. Su objetivo es crear un modelo de software que refleje de manera precisa las reglas, procesos y conceptos clave del área en la que opera la organización.

Existen dos aproximaciones a DDD, el diseño estratégica y el táctica.

Diseño estratégico.

La visión estratégica se centra en el diseño general y la organización del sistema a alto nivel. Esta aproximación busca entender el dominio de negocio en su totalidad, identificando las áreas clave y cómo se relacionan entre sí. Se enfoca en los objetivos de negocio y en cómo el software puede alinearse con ellos.

Dominio y Subdominio

Un Dominio representa lo que hace un negocio, incluyendo todo el conocimiento relacionado con el negocio y cómo opera. También representa los problemas que enfrenta el negocio que estás tratando de resolver. Un Subdominio es una subparte del dominio general, que representa un único y lógico modelo de dominio que descompone todo tu dominio de negocio.

Bounded context o contexto delimitado

Un Bounded Context es una frontera contextual semántica; en él, cada componente tiene un significado específico y realiza ciertas tareas. DDD trata con modelos grandes dividiéndolos en diferentes contextos delimitados interconectados.

La definición de los Bounded Contexts es el patrón central en el diseño estratégico de DDD que se ocupa de modelos grandes y equipos. La integración entre Bounded Contexts se conoce como Context Mappings. Existen diferentes estilos de integración (como RPC, HTTP RESTful y mensajería) y varios tipos de relaciones de Mapeo de Contexto (como Asociación, Cliente-Proveedor y Capa de Anticorrupción).

Lenguaje Ubicuo

El Lenguaje Ubicuo es un lenguaje común que es desarrollado por el equipo para crear el modelo de software que funciona con el Bounded Context. Se utiliza entre todos los miembros del equipo y los usuarios. El Lenguaje Ubicuo es riguroso, idealmente basado en el modelo de dominio utilizado en el software.

El Lenguaje Ubicuo es el nexo de unión entre la visión estratégica y la táctica porque el objetivo es trasladar los conceptos de dominio de todas las conversaciones funcionales y técnicas al código fuente que implemente el dominio.

Diseño táctico.

La aproximación táctica, en contraste, se ocupa de los detalles específicos de la implementación del modelo de dominio.

Entidad

Una Entidad es un objeto con una identidad distinta que transcurre a través del tiempo y diferentes representaciones. También se le conoce como objeto de referencia.

Value Object u objeto de valor.

Un Value Object es un objeto que importa solo como la combinación de sus atributos. Dos objetos de valor con los mismos valores para todos sus atributos se consideran iguales.

Agregado

Un Agregado es un grupo de entidades y objetos de valor que se pueden tratar como una única unidad. Un agregado tiene una raíz de agregado. Las referencias desde fuera del agregado solo deben ir a la raíz del agregado. Los agregados son el elemento básico de la transferencia de almacenamiento de datos. Cada agregado forma un límite de consistencia transaccional. Esto significa que dentro de un único agregado, todas las partes compuestas deben ser consistentes cuando la transacción controladora se compromete al almacenamiento de datos, de acuerdo con las reglas del negocio.

Servicio

Un Servicio es una operación independiente dentro del contexto de tu dominio.

Objeto de Servicio

Un Objeto de Servicio reúne uno o más Servicios en un objeto.

Evento de Dominio

Un Evento de Dominio es un registro de alguna ocurrencia significativa para el negocio en un contexto delimitado.

5. Mapeando los conceptos de BIAN a DDD.

Aunque BIAN y DDD provienen de contextos distintos, ambos buscan modularizar y simplificar sistemas complejos mediante la delimitación clara de responsabilidades y la definición de dominios de negocio.

Visión estratégica

Business Domain (BIAN) vs. Domain/Subdomain (DDD)

BIAN organiza el dominio del negocio bancario en Subdominios llamados Business Domains, que se agrupan a su vez en áreas más amplias llamadas Business Areas. Estos subdominios representan partes funcionales específicas de la operación bancaria, como pagos, gestión de cuentas o riesgo.

En DDD, los Subdominios son divisiones más pequeñas dentro del dominio principal de negocio, que encapsulan una lógica específica y consistente. Así, los Business Domains en BIAN se pueden mapear directamente a Subdominios de DDD, ya que ambos descomponen el negocio en áreas manejables.

Así, «Loans and Deposits».

Service Domain (BIAN) vs. Bounded Context (DDD)

Cada Service Domain en BIAN representa una unidad funcional que gestiona un activo o proceso específico. Estos dominios están claramente delimitados y se enfocan en una entidad de negocio principal, como una cuenta corriente o un préstamo al consumo.

En DDD, el concepto equivalente es el de Bounded Context, que define un límite claro dentro del cual un modelo específico del dominio opera sin interferencia externa. El Service Domain de BIAN se puede mapear a un Bounded Context en DDD, ya que ambos conceptos encapsulan datos y operaciones relacionados con un único enfoque dentro de un límite definido.

Así, «Current account» será un Bounded Context, diferenciado de «Savings account» o «Term deposit».

Lenguaje Ubicuo

El concepto de lenguaje ubicuo es fundamental en BIAN, ya que ofrece un marco común para describir las capacidades empresariales de un banco, lo que hace, la información que necesita y los servicios que ofrece y requiere. Este lenguaje es desarrollado por los bancos miembros y ha sido adoptado cada vez más por instituciones financieras y proveedores de software en el sector.

Este lenguaje es riguroso y se ha integrado en la arquitectura empresarial y en soluciones específicas por parte de los bancos y sus proveedores. Al establecer un vocabulario común, BIAN mejora la interoperabilidad tanto dentro de un mismo proyecto como entre diferentes proyectos, facilitando la colaboración entre bancos y proveedores de soluciones.

Visión táctica

BIAN Control Record & Behavior Qualifier vs. DDD Aggregates

En BIAN, el Control Record contiene toda la información necesaria para gestionar una transacción completa, mientras que los Behavior Qualifiers subdividen el Control Record en contextos más específicos.

En DDD, estos conceptos mapean a los Aggregates, que son estructuras que agrupan entidades y objetos de valor dentro de un límite lógico. Todos los componentes de un Aggregate deben ser consistentes al momento de realizar una operación, al igual que en BIAN, donde los Control Records y Behavior Qualifiers representan contextos donde los datos deben mantenerse coherentes.

Así «Current Account Facility» sería el control record, es decir, aggregate root de «Current Account» y podemos acceder a Business Object Model (BOM) de Current Account.

BIAN Service Operations & Service Groups vs. DDD Services

Cada Service Domain de BIAN ofrece un conjunto de Service Operations, que son consumidas por otros dominios para completar sus tareas. Estas operaciones permiten que los dominios colaboren y completen flujos de trabajo más amplios.

En DDD, los Service Operations de BIAN se alinean con el concepto de Servicios de Dominio, que son responsables de orquestar las acciones de los objetos del dominio sin violar las reglas del contexto. Los Service Groups de BIAN, que agrupan las operaciones de un dominio, se pueden mapear a Service Objects en DDD.

https://bian.org/servicelandscape-12-0-0/object_20.html?object=243671

BIAN Events vs. DDD Domain Events

BIAN está ampliando sus especificaciones de dominios de servicio para incluir Eventos, que representan cambios o situaciones importantes dentro de un dominio. Estos eventos permiten una comunicación más asíncrona y basada en eventos entre los dominios de servicio.

En DDD, los Domain Events representan sucesos que alteran el estado del dominio, propagando esos cambios a otros contextos. Los Eventos de BIAN se pueden mapear a los Domain Events de DDD, ya que ambos permiten la coordinación y respuesta ante situaciones que afectan múltiples partes del sistema.

6. Definición de una arquitectura de servicios financieros basada en BIAN y DDD.

Tanto si estamos definiendo una arquitectura de servicios financieros desde cero como si nuestro objetivo es llevar a cabo la modernización de un sistema más tradicional hacía una orientación de servicios basada en DDD, BIAN se ha convertido en el estándar de referencia de facto en el mercado:

  • tanto si estamos creando desde cero nuestros bounded contexts, basados en un lenguaje ubicuo, podemos usar como referencia los Service Domain de BIAN, o
  • si estamos tratando de pegarle mordiscos al elefante, podemos tratar de delimitar el diámetro de nuestras mandíbulas mapeando los conceptos del sistema actual con el ámbito de los Services Domains de BIAN.

En ambos casos la aproximación recomendada es bottom-up, tratando de identificar los servicios de dominio a partir de las entidades y el comportamiento que queremos delimitar en base a un lenguaje propio del mismo.

Y para ello, podemos acudir también a dos recursos de interoperabilidad:

Hace pocos años, la interoperabilidad se definía vía servicios SOAP y no existían estos eventos, es por eso también que ahora es mucho más atractivo que otras aproximaciones de mercado.

7. Referencias.

8. Conclusiones.

BIAN proporciona un estándar flexible y modular que, en combinación con principios de DDD, permite a las instituciones financieras modernizar sus sistemas de manera ágil y sin fricciones.

La arquitectura basada en servicios y el fácil mapeo entre el concepto de Service Domains de BIAN con el de Bounded Contexts en DDD, ayuda a minimizar los riesgos en la implementación y a fomentar una mayor interoperabilidad, alta cohesión y bajo acoplamiento, entre distintos sistemas.

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad