Architecture

Inner Workings

Logical view

img.png

Processing Flows

Inventory Processing

  1. Incoming inventory updates arrive to the system via the ims-pi-tmf-gateway or ims-si-tmf-gateway and are queued on the Event Bus.
  2. Inventory data is validated through the ims-lock microservice to ensure consistency and prevent conflicts.
  3. The ims-inventory microservice performs validation of each operation to ensure its correctness.
  4. Once validated, the ims-inventory updates the inventory data stored in MongoDB.
  5. The ims-callback microservice handles callbacks to external systems regarding the updates.
  6. All processes are monitored by the audit-log (ims-task) microservice, ensuring traceability and auditability.

Throughout the inventory processing, the communication is asynchronous thanks to the Event Bus, and state persistence is achieved via MongoDB. Further mentions of these components are omitted for clarity.

Errors

Each component in the system can encounter errors during processing. These errors are managed and logged for resolution by the audit-log (ims-task) microservice.

  1. When an error occurs, the responsible microservice reports it to the audit-log (ims-task).
  2. The audit-log (ims-task) () records the error.
  3. GUI provides a mechanisms for human resolution actions.

Components

ims-pi-tmf-gateway/ims-si-tmf-gateway

Java microservices providing a TMF-compliant REST API for integrating with external systems. They receive inventory updates and forward them to the Event Bus.

  • ims-pi-tmf-gateway is used for handling product inventory.
  • ims-si-tmf-gateway is used for handling service inventory.

ims-inventory

A Java microservice responsible for creating, modifying, and deleting inventory items. It performs validation of inventory data and updates the MongoDB database accordingly.

ims-inventory-view

A Java microservice responsible for retrieving inventory data with filtering capabilities. It interacts with the MongoDB database to provide relevant inventory states.

ims-lock

This microservice handles validation and locking mechanisms to ensure data consistency and prevent concurrent modifications.

ims-callback

Handles informing clients that the task they submitted has been completed.

audit-log (ims-task)

A Java microservice that logs all system activities and errors, providing a comprehensive audit trail for monitoring and troubleshooting.

Architectural Principles

In developing our Inventory Management system, we adhered to a set of fundamental principles such as Command Query Responsibility Segregation (CQRS), Centralized Event Store, Domain-Driven Design (DDD), Behavior-Driven Development (BDD), and Hexagonal Architecture. These principles guided our efforts to create a reliable, scalable, and functional platform. By embracing these principles, we've ensured that our system maintains High Availability (HA), Fault Tolerance (FT), scalability, transactional consistency, and thorough audit capabilities. Our focus is on building a system that prioritizes reliability and efficiency for our users and stakeholders.

Command Query Responsibility Segregation

CQRS is a design pattern that separates the read and write operations of a data storage system into distinct interfaces. This separation allows for optimization of each operation and improves scalability.

Centralized Event Store

A Centralized Event Store acts as the backbone for an Event-Driven Architecture, providing a single source of truth for all events within the system. This store records events in an immutable sequence, allowing systems to reconstruct past states.

Domain-Driven Design

Domain-Driven Design (DDD) is a methodology that focuses on the core domain logic of the application, placing primary importance on the complex needs of the domain itself.

Behavior-Driven Development

Behavior-Driven Development (BDD) is an approach to software development that encourages collaboration among developers, QA, and non-technical participants. BDD focuses on obtaining a clear understanding of desired software behavior through discussion with stakeholders.

Hexagonal Architecture

Hexagonal Architecture, also known as Ports and Adapters Architecture, promotes the separation of concerns by externalizing the inputs and outputs of the application. The core logic of the application resides within the hexagon, while interactions with the outside world occur through ports and adapters.