Billing Bounded Context

Relevant source files

The following files were used as context for generating this wiki page:

• Core/Billing/Billing.Domain/BillingProfiles/BillingProfile.cs
• Core/Billing/Billing.Infrastructure/Consumers/MassTransit/PatientCreatedIntegrationEventHandler.cs
• Core/Billing/Billing.Application/BillingProfiles/Commands/CreateBillingProfileCommand.cs
• Core/Billing/Billing.Infrastructure/Persistence/BillingDbContext.cs
• WebApplications/Billing.WebApi/Program.cs
• Core/Billing/Billing.Infrastructure/Persistence/Migrations/BillingDbContextModelSnapshot.cs
• claude.md

The Billing Bounded Context is a core module within the DDD learning project responsible for managing financial profiles and payment information for patients. It operates primarily as a downstream consumer of the Scheduling Bounded Context, reacting to patient creation events to automatically establish billing capabilities.

The context is built using Domain-Driven Design (DDD) tactical patterns, including Aggregates, Value Objects, and Domain Events. It leverages a CQRS architecture via MediatR and implements asynchronous inter-service communication using either MassTransit or Wolverine as the message bus.

Sources: claude.md:27-28, claude.md:120-125

Domain Model

The central aggregate of this context is the BillingProfile. It encapsulates the financial identity of a patient, including contact details and payment methods.

BillingProfile Aggregate

The BillingProfile entity serves as the Aggregate Root. It is created with a reference to a PatientId from the Scheduling context, ensuring a link between clinical and financial records.

The diagram shows the relationship between the BillingProfile Aggregate Root and its owned PaymentMethod Value Object.
Sources: BillingProfile.cs:7-21, BillingDbContextModelSnapshot.cs:238-261

Domain Logic and Events

State changes within the BillingProfile are signaled via Domain Events. When a profile is instantiated using the static Create factory method, a BillingProfileCreatedEvent is raised.

• Encapsulation: Properties have private setters to ensure state is only modified through valid domain methods.
• Immutability: The PaymentMethod is treated as a complex value type owned by the profile.

Sources: BillingProfile.cs:25-44, BillingDbContextModelSnapshot.cs:238-251

Application Logic (CQRS)

The application layer implements the write-side of CQRS using commands and validators.

Create Billing Profile Command

The primary entry point for creating data is the CreateBillingProfileCommand. This command is validated for data integrity and business rules before processing.

Rule	Description	Error Code
Patient Presence	Validates that the PatientId is provided.	Required
Unique Profile	Checks if a billing profile already exists for the patient.	Conflict
Email Format	Ensures the provided email follows standard patterns.	InvalidEmail

Sources: CreateBillingProfileCommand.cs:13-68

Infrastructure and Integration

The Billing context is designed to be reactive, responding to events published by other services.

Integration Event Handling

When a patient is created in the Scheduling context, a PatientCreatedIntegrationEvent is published. The Billing context consumes this event to create a corresponding BillingProfile.

This flow illustrates the asynchronous integration between Scheduling and Billing.
Sources: PatientCreatedIntegrationEventHandler.cs:18-24, Program.cs:51-68

Persistence and Outbox

Persistence is handled by EF Core 9 with SQL Server. To ensure reliable messaging, the context implements the Transactional Outbox pattern.

• Inbox/Outbox Tables: The BillingDbContext includes tables for Billing_InboxState, Billing_OutboxMessage, and Billing_OutboxState to track message delivery and prevent duplicate processing.
• Database Schema: The BillingProfiles table stores the aggregate data, with PaymentMethod fields mapped as owned properties (prefixed with PaymentMethod).

Sources: BillingDbContext.cs:18-24, BillingDbContextModelSnapshot.cs:46-236

Configuration

The infrastructure is flexible, allowing a choice between messaging frameworks via configuration.

Setting	Type	Purpose
MessagingFramework	string	Switch between Wolverine and MassTransit (Default: Wolverine).
ConnectionStrings:DefaultConnection	string	SQL Server connection string for the billing database.
Cors:AllowedOrigins	string[]	Authorized origins for the Web API (e.g., Angular SPA).

Sources: Program.cs:30-33, Program.cs:51-78

Summary

The Billing Bounded Context provides an automated financial onboarding process for patients. By utilizing a reactive, event-driven approach and the Transactional Outbox pattern, it maintains eventual consistency with the Scheduling context while ensuring robust data persistence and domain integrity.