Files
lmnp-organizer/docs/adr/0014-strict-ddd-rental-management.md
T
nessar e02ad54bcb feat: add unit and integration tests for rental management domain
- Introduced RentPaymentCorrectionTest and RentPaymentTest to validate payment and refund logic.
- Added PhoneNumberTest to ensure proper normalization of phone numbers.
- Created TenantTest to verify attachment management and tenant referencing.
- Implemented ReplacementRentalApiJourneyIT for end-to-end testing of rental and payment workflows.
- Documented architectural decisions in ADR-0014, emphasizing strict DDD boundaries and transaction management.
2026-08-17 14:18:15 +02:00

2.9 KiB

Use strict DDD boundaries for Rental Management

Status: accepted

ADR-0012 kept the first Rental Management refactor deliberately pragmatic. That structure left business rules coupled to Spring Data documents and technical-layer packages, and its single-process integrity lock could not protect multiple application instances.

The backend now uses one modular-monolith bounded context with:

  • framework-independent aggregates, value objects, domain events, rules, and repository contracts under rental/domain;
  • application use cases and outbound ports under rental/application;
  • HTTP/OIDC inbound adapters and MongoDB, filesystem, identity, and PDF outbound adapters under rental/adapter;
  • explicit composition in RentalApplicationConfiguration.

Spring Data documents are private to the MongoDB adapters. They map domain versions to @Version fields and every portfolio query and mutation includes the authenticated LandlordId; landlord identity registration uses the deterministic oidc:<subject> landlord ID. The application disables legacy Spring Data repository discovery so obsolete persistence models and indexes cannot become active accidentally. Because repository auto-configuration is disabled, the Mongo adapter explicitly resolves and creates the replacement documents' annotated indexes at startup, including unique integrity constraints.

Multi-aggregate operations use MongoDB transactions and optimistic aggregate versions. Development and integration-test MongoDB therefore run as a replica set. A versioned apartment-occupancy aggregate serializes competing lease activations for the same apartment; versioned dues and payments reject concurrent balance changes; activation, amendments, allocation, reversal, and refund confirmation commit or roll back as one unit. The single-process RentalIntegrityLock and manual database compensation are not part of the new runtime.

The filesystem cannot join a MongoDB transaction. Attachment deletion therefore stages a path-addressed, recoverable file move before the version-checked Mongo mutation, restores it when that mutation fails, and performs tombstone cleanup after success. On startup, uncommitted staging is restored and explicitly committed tombstones are discarded, preventing Mongo metadata from pointing at a file lost during a process crash. This local-filesystem recovery assumes one backend process owns the attachment root; horizontal scaling requires shared transactional object storage or an external reconciliation workflow. The boundary is explicit in the application storage port rather than hidden behind a database transaction annotation.

This supersedes ADR-0012 without introducing microservices, event sourcing, a message broker, or a second state-management mechanism. Existing REST contracts and development Mongo documents are intentionally replaceable; issue 24 explicitly permits resetting development data and requires no production migration.