Refactor OpenFactstore to Decoupled CQRS Architecture

[MaximumTrainer]

Context: We are refactoring the OpenFactstore repository (https://github.com/MaximumTrainer/OpenFactstore) to move from a basic structure to a fully decoupled CQRS (Command Query Responsibility Segregation) architecture. The goal is to separate the Write and Read concerns at the code, database, and deployment levels.

1. Code & Logical Separation

• Modules: Segregate the codebase into two distinct modules/packages: factstore-command (Write side) and factstore-query (Read side).
• Dependencies: Ensure the Query module has no direct dependency on the Command module’s domain logic. Communication should be strictly event-driven.
• Projections: Implement a "feed" mechanism where every state-changing event in the Write database triggers an update (projection) to the Read database.

2. Database Strategy

• Production/Deployed: * Write Database: Use a standalone PostgreSQL instance optimized for writes/transactions.
  • Read Database: Use a separate PostgreSQL instance optimized for complex queries and materialized views.
• Testing: * Use separate H2 in-memory databases for the Command and Query tests to ensure full isolation and high-speed execution.

3. Messaging & Event Bus

• Production Profile: Implement RabbitMQ as the message broker to handle the event feed from the Write side to the Read side. Ensure the connection is robust and tested for the "deployed" version.
• Test Profile: For integration testing, swap RabbitMQ with an In-memory Queue (e.g., Spring's SimpMessagingTemplate or a custom internal bus) to allow tests to run without external dependencies.

4. Deployment & Documentation

• Infrastructure as Code: Update the docker-compose.yml and any Kubernetes manifests to include:
  • Two separate PostgreSQL services.
  • A RabbitMQ service.
  • Separate deployment containers for the Command and Query services.
• Documentation: Update README.md and DEPLOYMENT.md to reflect the new architecture, including the network topology, environment variables for the dual databases, and the event-driven synchronization flow.

5. Task Requirements

1. Initialize the dual-database configuration in the application profiles (application-prod.yml, application-test.yml).
2. Refactor existing Repository and Service classes into their respective CQRS modules.
3. Implement the Event Listener/Publisher logic using RabbitMQ for the live feed.
4. Ensure all existing tests are updated to use H2 and the in-memory queue.
5. Ensure all tests & deployments worlk
6. Ensure command line tool can access, read & write to the correct API's
7. Ensure data is replicated from write to read services, including post deployment verification tests