Arquitectura Plataforma Extendida Y Extended Java Backend Architecture

ASO Y APX

Una forma sencilla de separar ASO y APX es: ASO es la capa de servicios y APIs, y APX es la plataforma backend que ejecuta la lógica transaccional.

En un sistema bancario, el canal (web, móvil, etc.) no debería contener toda la lógica del negocio. El canal consume servicios. Esos servicios deben estar desacoplados, reutilizables, versionables y gobernados.

Una visión conceptual simplificada es:

Cliente / Canal
      |
      v
+-------------------+
|      ASO          |
| Servicios / APIs  |
+-------------------+
      |
      v
+-------------------+
|       APX         |
| Backend / lógica  |
| transaccional     |
+-------------------+
   |       |      |
   v       v      v
  BD     Host   Servicios

No significa que toda la arquitectura del banco tenga exactamente esta secuencia física. Es un modelo mental para distinguir responsabilidades.

Se describe históricamente ASO como una arquitectura de servicios de tres capas orientada a simplificar, modularizar y reutilizar servicios tecnológicos. En documentación pública de empleo, ASO aparece además asociado al ciclo de vida de APIs REST, contratos API-First, versionado, paginación, seguridad, idempotencia y gestión unificada de errores.

APX, por su parte, aparece en documentación pública, como una arquitectura de procesamiento escalable y de menor coste, orientada a absorber grandes volúmenes de transacciones. Los materiales de formación relacionados con APX la describen como una plataforma backend Java para ejecutar lógica de negocio y operaciones transaccionales fuera o en colaboración con entornos de mainframe.

Qué es ASO y para qué sirve

ASO puede entenderse como la arquitectura o capa de servicios que expone capacidades de negocio mediante APIs y servicios reutilizables.

Su responsabilidad principal no es "ser la base de datos" ni "ser el canal". Su responsabilidad es ofrecer un contrato de servicio claro entre consumidores y la lógica backend.

Ejemplo de negocio:

GET /clientes/12345/cuentas

El consumidor no necesita saber:

• dónde está almacenada la información,
• qué componente la obtiene,
• si se consulta una o varias fuentes,
• qué implementación interna se utiliza.

El consumidor necesita conocer:

• URL y recurso,
• versión,
• parámetros,
• respuesta,
• errores,
• reglas de seguridad.

Eso es un principio fundamental de una API: ocultar implementación y publicar contrato.

ASO y API

En la práctica moderna, un servicio ASO puede exponerse mediante REST.

Ejemplo conceptual:

GET /api/v1/accounts/12345

Respuesta:

{
  "customerId": "12345",
  "accounts": [
    {
      "id": "001",
      "currency": "MXN",
      "availableBalance": 12500.50
    }
  ]
}

El consumidor conoce el contrato JSON, no la implementación interna.

Conceptos que debes saber explicar:

• REST: estilo de comunicación basado en recursos HTTP.
• API: contrato que define cómo un sistema puede ser consumido.
• Versionado: permite evolucionar una API sin romper consumidores existentes.
• DTO: objeto usado para transportar datos de forma explícita.
• Idempotencia: repetir una operación idempotente produce el mismo efecto final.
• Validación: los datos de entrada deben comprobarse antes de aplicar lógica.
• Manejo de errores: los errores deben ser consistentes y útiles para el consumidor.

En una vacante reciente de para arquitectura de ASO se mencionan expresamente REST, OpenAPI/Swagger, JSON Schema, JWT, API-First, versionado, paginación, idempotencia, errores unificados, JUnit 5, Mockito y Postman.

Ejemplo de ASO con Spring Boot

El siguiente ejemplo NO pretende reproducir las clases internas. Es un ejemplo de cómo se estructura un servicio REST en Java/Spring con responsabilidades separadas.

DTO:

public record AccountResponse(
    String id,
    String currency,
    BigDecimal availableBalance
) {}

Servicio:

public class AccountService {

    public AccountResponse findAccount(String accountId) {
        // La implementación real podría consultar una librería,
        // un repositorio o una capacidad backend.
        return new AccountResponse(
            accountId,
            "MXN",
            new BigDecimal("12500.50")
        );
    }
}

Controller:

@RestController
@RequestMapping("/api/v1/accounts")
public class AccountController {

    private final AccountService service;

    public AccountController(AccountService service) {
        this.service = service;
    }

    @GetMapping("/{id}")
    public AccountResponse getAccount(@PathVariable String id) {
        if (id == null || id.isBlank()) {
            throw new IllegalArgumentException("accountId is required");
        }

        return service.findAccount(id);
    }
}

La idea arquitectónica importante es:

HTTP
  |
  v
Controller
  |
  v
Service
  |
  v
Acceso a capacidades/datos

No conviene meter toda la lógica de negocio dentro del Controller.

POM de un servicio Java/Spring

Ejemplo simplificado de Maven:

<project>
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>account-service</artifactId>
    <version>1.0.0</version>

    <properties>
        <java.version>17</java.version>
        <spring-boot.version>3.x.x</spring-boot.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-validation</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

Comandos esenciales:

mvn clean package
mvn test

IMPORTANTE: la versión real de Java/Spring depende de la plataforma y del proyecto. Fuentes públicas recientes muestran entornos con Java 17/21 y Spring Boot 3+, mientras que otras vacantes mencionan Java 8/11 o superior. Por eso conviene aprender el patrón y no asociar APX/ASO a una única versión universal.

Qué es APX

APX es una arquitectura o plataforma backend utilizada para ejecutar servicios, transacciones y procesos de negocio con un modelo orientado a alto rendimiento, escalabilidad y desacoplamiento.

Históricamente, se describió APX como una arquitectura de procesamiento de bajo coste y escalable, utilizada para absorber grandes volúmenes de transacciones y trasladar cargas fuera de entornos de procesamiento más costosos.

Los materiales de formación relacionados con APX la presentan como una plataforma backend Java que puede trabajar en colaboración con Mainframe o de forma independiente.

La idea esencial:

Java + plataforma APX + componentes de negocio
                       |
                       v
                  Transacción

APX proporciona capacidades de infraestructura y transacción para que el desarrollador no tenga que resolver manualmente problemas que, en un banco, son críticos: transaccionalidad, conectividad controlada, observabilidad, reglas, acceso a datos, manejo de operaciones y ejecución segura.

APX Online

APX Online está orientado a la ejecución de operaciones en línea, donde una petición llega y la respuesta se necesita como parte del flujo de la operación.

Ejemplo:

Cliente
  |
  | solicitud HTTP
  v
Servicio/API
  |
  v
APX Online
  |
  +--> lógica de negocio
  |
  +--> datos
  |
  +--> servicio externo
  |
  v
respuesta

Casos conceptuales:

• consultar saldo,
• registrar una operación,
• validar una condición,
• realizar una operación bancaria,
• obtener información calculada en tiempo real.

La característica clave es que existe interacción con una petición concreta y su resultado.

Contexto transaccional

En la guía de estudio revisada se describe una Capa de Control que participa en el dispatch de transacciones y proporciona el contexto transaccional, incluyendo la posibilidad de commit o rollback y la ejecución de acciones previas y posteriores a la lógica de negocio.

Conceptualmente:

Petición
  |
  v
Control transaccional
  |
  v
Lógica de negocio
  |
  +---- acceso a datos
  |
  +---- invocaciones permitidas
  |
  v
Commit / Rollback

¿Por qué importa? Porque una operación bancaria puede tocar varios recursos y no debe quedar en un estado parcial por un fallo intermedio.

Ejemplo conceptual:

transferir(1000)

1. validar origen
2. descontar 1000
3. acreditar 1000
4. registrar operación
5. confirmar

Si algo crítico falla antes de la confirmación, el modelo transaccional debe impedir que la operación quede lógicamente incompleta.

APX Batch

APX Batch está orientado a procesamiento por lotes, especialmente cuando se deben procesar volúmenes grandes de información o ejecutar procesos de negocio sin interacción directa del usuario.

Ejemplo:

Archivo / BD
    |
    v
  Reader
    |
    v
  Processor
    |
    v
  Writer
    |
    v
 Resultado

Un proceso Batch puede ejecutarse de forma programada mediante un planificador y puede tener varias etapas.

La guía consultada indica que APX Batch está basado en Spring Batch y menciona características como soporte multi-BBDD, acceso a conectores y utilidades APX, ejecución de múltiples transacciones, lectura y escritura en distintos formatos y mecanismos de reinicio o confirmaciones parciales según la arquitectura.

Job, Step y Chunk

Modelo mental:

JOB
 |
 +-- STEP 1
 |     |
 |     +-- Reader
 |     +-- Processor
 |     +-- Writer
 |
 +-- STEP 2
       |
       +-- Task

Un Job es el proceso completo.

Un Step es una etapa del Job.

En un Step tipo Chunk:

itemReader
    |
    v
itemProcessor
    |
    v
itemWriter

Ejemplo conceptual:

• Reader: lee una cuenta.
• Processor: calcula la transformación o regla.
• Writer: guarda el resultado.

Ejemplo de Spring Batch

El siguiente código es un ejemplo didáctico basado en Spring Batch.

@Bean
public Step processAccounts(
        JobRepository jobRepository,
        PlatformTransactionManager transactionManager,
        ItemReader<Account> reader,
        ItemProcessor<Account, AccountResult> processor,
        ItemWriter<AccountResult> writer) {

    return new StepBuilder("processAccounts", jobRepository)
        .<Account, AccountResult>chunk(100, transactionManager)
        .reader(reader)
        .processor(processor)
        .writer(writer)
        .build();
}

Processor:

public class AccountProcessor
        implements ItemProcessor<Account, AccountResult> {

    @Override
    public AccountResult process(Account account) {

        BigDecimal balance = account.getBalance();

        return new AccountResult(
            account.getId(),
            balance.signum() >= 0 ? "VALID" : "REVIEW"
        );
    }
}

La idea no es memorizar la sintaxis completa, sino entender la separación:

READ -> PROCESS -> WRITE

Esto permite dividir responsabilidades y procesar grandes cantidades de registros sin escribir un único método gigante.

Regla crítica: hilos en APX Batch

Uno de los puntos que más importa en APX Batch es no tratar el paralelismo como en una aplicación Java común.

La documentación de formación relacionada con APX indica que la creación o gestión directa de hilos por las aplicaciones no está permitida.

Por tanto, NO debes resolver un batch haciendo esto:

Thread thread = new Thread(() -> {
    process();
});

Tampoco:

ExecutorService pool = Executors.newFixedThreadPool(10);

y luego:

pool.submit(() -> process());

¿Por qué? Porque la arquitectura de ejecución de un entorno bancario debe controlar: concurrencia, recursos, trazabilidad, reintentos, estado del Job, errores, capacidad de recuperación, despliegue y operación.

El desarrollador define la lógica del proceso y la arquitectura o framework controla la forma segura de ejecutar ese proceso.

Regla para recordar: "No creo mis propios hilos en APX Batch. Dejo que la arquitectura gestione la ejecución."

ASO vs APX: diferencia práctica

Piensa así:

• ASO responde a "¿Cómo publico y consumo una capacidad?"
• APX responde a "¿Dónde y con qué arquitectura ejecuto la lógica backend?"

Ejemplo: un cliente solicita "Consultar movimientos de cuenta".

ASO:

• define y exhibe el servicio,
• define el contrato,
• recibe la petición,
• valida la interfaz,
• entrega la respuesta.

APX:

• ejecuta la lógica backend,
• aplica reglas de negocio,
• utiliza las capacidades autorizadas para datos,
• gestiona el contexto transaccional cuando corresponde.

No es obligatorio que cada implementación concreta sea idéntica a este dibujo, pero este modelo sirve para explicar responsabilidades.

Componentes y librerías en APX

Uno de los conceptos centrales de APX es evitar que todo el código esté concentrado en una única clase o módulo.

La guía de estudio destaca tres conceptos muy útiles: Transacción, Librería y DTO.

• Transacción: contiene u orquesta la lógica correspondiente a una operación concreta.
• Librería: encapsula funcionalidad reutilizable y capacidades de acceso o control que deben ser compartidas de forma estructurada.
• DTO: transporta datos agrupados de forma explícita entre componentes.

Ejemplo:

Transaction
     |
     +--> CustomerLibrary
     |
     +--> AccountLibrary
     |
     +--> TransferDTO

La guía también insiste en evitar árboles de dependencias excesivos y en controlar el número de librerías invocadas. El objetivo arquitectónico es reducir acoplamiento, complejidad y riesgo operativo.

Anti-patrón Blob

Un error clásico es convertir una librería en un "Blob":

public class EverythingLibrary {

    public void execute1() {}
    public void execute2() {}
    public void execute3() {}
    public void execute4() {}
    public void execute5() {}
    // ...
}

El problema: demasiadas responsabilidades, difícil de probar, difícil de reutilizar, fuerte acoplamiento y cambios con impacto amplio.

Una mejor estructura es separar por responsabilidad:

CustomerLibrary
AccountLibrary
PaymentLibrary
ValidationLibrary

No significa crear una clase por cada línea de código. Significa que cada componente tenga una responsabilidad coherente y estable.

Acceso a datos

En un banco, "puedo abrir una conexión JDBC" no significa "debo abrirla directamente".

La guía de estudio consultada indica como buenas prácticas:

• una unidad de aplicación debe respetar la custodia de los datos,
• el acceso a datos de terceros se realiza mediante capacidades o librerías autorizadas,
• no se debe gestionar directamente el objeto DataSource,
• no se deben instanciar, abrir o cerrar manualmente las conexiones.

Ejemplo que NO representa una buena práctica arquitectónica:

Connection connection = dataSource.getConnection();

try {
    // SQL
} finally {
    connection.close();
}

La idea es que el framework o capa autorizada administre recursos y que la aplicación consuma la abstracción prevista.

Esto reduce errores de: conexiones olvidadas, fugas de recursos, configuración duplicada y acceso no gobernado.

Invocaciones asíncronas entre transacciones

Otro punto relevante de APX son las restricciones de invocación entre transacciones.

La guía consultada establece que la invocación asíncrona entre transacciones debe tratarse con criterios concretos y que una transacción asíncrona no debe encadenarse libremente con otra transacción asíncrona.

La razón conceptual es importante:

APX Online
    |
    +--> transacción A
           |
           +--> llamada controlada
                   |
                   v
               transacción B

No conviene convertir el sistema en:

A -> B -> C -> D -> E -> F ...

porque aumenta: latencia, dependencias, dificultad de trazabilidad, errores distribuidos y complejidad de recuperación.

En un examen o entrevista, la idea importante es: "Las invocaciones entre transacciones están gobernadas por restricciones arquitectónicas; no se diseñan como llamadas libres entre cualquier componente."

Manejo de errores y logs

En software bancario no basta con "hacer catch y mostrar error".

El error debe ser: identificable, trazable, consistente, útil para operación y separable entre error de negocio y error técnico.

Ejemplo conceptual:

if (amount.compareTo(balance) > 0) {
    throw new BusinessException("INSUFFICIENT_FUNDS");
}

No se debe esconder un error:

try {
    process();
} catch (Exception e) {
    return null;
}

Eso destruye la trazabilidad.

La guía consultada también distingue niveles de log como INFO, WARN y ERROR para seguimiento y situaciones anómalas. En una arquitectura bancaria el log no es sólo para depurar: es parte de la operación y de la trazabilidad.

Seguridad

Las reglas exactas dependen del proyecto, pero hay principios que debes explicar:

1. Validar entradas.
2. No confiar en datos provenientes del cliente.
3. No guardar secretos en el código.
4. Aplicar autenticación y autorización según el contrato.
5. Evitar exponer información sensible.
6. Mantener trazabilidad de operaciones.
7. No implementar mecanismos de infraestructura que la plataforma ya gobierna.

En servicios REST actuales asociados a arquitectura ASO, se publican referencias a OpenAPI/Swagger, JSON Schema y JWT, además de seguridad, idempotencia y gobierno de APIs.

Ejemplo conceptual de validación:

public void validateAmount(BigDecimal amount) {
    if (amount == null || amount.signum() <= 0) {
        throw new IllegalArgumentException(
            "amount must be greater than zero"
        );
    }
}

La validación no sustituye las reglas de negocio. Son capas diferentes:

Validación técnica
      |
      v
Reglas de negocio
      |
      v
Operación

Ejemplo completo: flujo ASO + APX

Supongamos una operación:

POST /api/v1/transfers

Petición:

{
  "sourceAccount": "001",
  "targetAccount": "002",
  "amount": 500.00
}

Flujo conceptual:

1. ASO recibe POST /transfers
          |
          v
2. valida estructura y autenticación
          |
          v
3. transforma JSON -> DTO
          |
          v
4. invoca capacidad backend
          |
          v
5. APX ejecuta lógica transaccional
          |
          +--> valida saldo
          |
          +--> debita origen
          |
          +--> acredita destino
          |
          +--> registra operación
          |
          v
6. commit
          |
          v
7. APX devuelve resultado
          |
          v
8. ASO construye respuesta
          |
          v
9. HTTP 201 / 200 según contrato

DTO:

public record TransferRequest(
    String sourceAccount,
    String targetAccount,
    BigDecimal amount
) {}

Servicio de negocio:

public class TransferService {

    public TransferResult transfer(TransferRequest request) {

        validate(request);

        // Ejemplo conceptual:
        // debit(request.sourceAccount(), request.amount());
        // credit(request.targetAccount(), request.amount());
        // registerOperation(request);

        return new TransferResult("ACCEPTED");
    }

    private void validate(TransferRequest request) {
        if (request == null) {
            throw new IllegalArgumentException("request is required");
        }

        if (request.amount() == null ||
            request.amount().signum() <= 0) {
            throw new IllegalArgumentException("amount is invalid");
        }
    }
}

La lección importante: el Controller no debería contener toda la operación bancaria. La capa de servicio tampoco debería abrir manualmente conexiones o crear hilos. La plataforma y sus componentes autorizados deben encargarse de esas preocupaciones.

Ejemplo de batch completo

Supongamos que a las 02:00 se procesan 2 millones de registros.

Scheduler
    |
    v
  JOB
    |
    +--> STEP 1: lectura
    |
    +--> STEP 2: procesamiento
    |
    +--> STEP 3: escritura
    |
    v
resultado

Dentro de un Chunk:

100 registros
    |
    v
  Reader
    |
    v
  Processor
    |
    v
  Writer

Después continúa el siguiente bloque.

Ventajas:

• menor complejidad que procesar todo en memoria,
• control del avance,
• posibilidad de reinicio según configuración,
• responsabilidades separadas,
• mejor integración con el framework de batch.

Código conceptual:

@Bean
public ItemProcessor<Account, AccountResult> processor() {
    return account -> {

        if (account.getBalance().signum() < 0) {
            return new AccountResult(account.getId(), "REVIEW");
        }

        return new AccountResult(account.getId(), "OK");
    };
}

Writer conceptual:

@Bean
public ItemWriter<AccountResult> writer(AccountRepository repository) {
    return items -> {
        for (AccountResult item : items) {
            repository.save(item);
        }
    };
}

No se agrega ningún Thread, ExecutorService o pool manual.

Qué memorizar para explicarlo en una entrevista

• ASO: "Es la arquitectura o capa de servicios para exponer capacidades de negocio mediante servicios y APIs desacoplados, reutilizables y gobernados. Está muy relacionada con APIs REST, contratos, versionado, seguridad, paginación e idempotencia."
• APX: "Es una plataforma backend orientada a ejecutar lógica de negocio y transacciones de forma escalable, con capacidades de infraestructura y control transaccional."
• APX Online: "Ejecuta operaciones en línea, asociadas a una petición que necesita respuesta en tiempo de ejecución."
• APX Batch: "Ejecuta procesos por lotes, normalmente sobre grandes volúmenes, usando un modelo de Jobs y Steps. El procesamiento típico separa Reader, Processor y Writer."
• Hilos: "No creo ni gestiono hilos directamente en APX Batch; la arquitectura controla la ejecución."
• DTO: "Objeto para transportar datos agrupados de manera explícita entre componentes."
• Librería: "Componente reutilizable que encapsula una responsabilidad o capacidad concreta."
• Transacción: "Representa una operación de negocio y orquesta su flujo dentro del modelo transaccional definido por la plataforma."

Diferencia en una tabla

Errores típicos que debes evitar

1. Meter toda la lógica en un Controller. Mejor: Controller, servicio o lógica, y capacidades autorizadas.
2. Crear una "MegaLibrería". Mejor: separar responsabilidades en librerías pequeñas y coherentes.
3. Abrir o cerrar manualmente conexiones de BD cuando la arquitectura proporciona una abstracción para acceder a datos. Mejor: consumir el mecanismo de acceso autorizado por la plataforma.
4. Crear Threads manualmente en Batch. Mejor: definir Job y Steps y dejar la ejecución al framework o arquitectura.
5. Usar catch(Exception) para ocultar problemas. Mejor: manejar errores de forma explícita y conservar la trazabilidad.
6. Hacer que las transacciones se llamen libremente unas a otras. Mejor: respetar las restricciones arquitectónicas de invocación.
7. Explicar ASO como si fuera simplemente "un REST Controller". Mejor: explicarlo como una arquitectura o capa de servicios con contrato, gobierno y reutilización.

Resumen final

La forma más útil de visualizar el ecosistema es esta:

            CONSUMIDOR
               |
               v
         +-----------+
         |    ASO    |
         | APIs /    |
         | servicios |
         +-----------+
               |
               v
         +-----------+
         |    APX    |
         +-----------+
            /     \
           /       \
          v         v
     APX Online   APX Batch
          |           |
    transacciones     Jobs
          |           |
     lógica           Steps
     negocio          Chunk
          |           |
          v           v
    datos / servicios / capacidades

Qué debes quedarte:

1. ASO se ocupa de la exposición y gobierno de servicios y APIs.
2. APX se ocupa de la ejecución backend y de capacidades transaccionales.
3. APX Online es para ejecución en línea.
4. APX Batch es para procesamiento por lotes.
5. Batch trabaja alrededor de Jobs, Steps y patrones como Reader, Processor y Writer.
6. En APX no se debe crear ni gestionar hilos de forma manual.
7. Los DTOs transportan datos; las librerías encapsulan capacidades; las transacciones orquestan operaciones.
8. La arquitectura busca bajo acoplamiento, reutilización, trazabilidad, seguridad y escalabilidad.
9. Los detalles exactos de APIs, paquetes, versiones y utilidades internas dependen del entorno concreto.

© Arturo Juárez Monroy