LedgerVue

At first glance, consolidating portfolio performance across asset classes looks straightforward. A family office tracks traditional securities (stocks, bonds), private equity fund commitments (as a Limited Partner), and alternative assets (yachts, art, real estate). For reporting purposes, you need to answer basic questions: What is my total wealth? What's my return across all holdings? How much cash went in and out this year?

From a reporting perspective, this seems entirely achievable. Assets have values. Cash flows happen. Calculate the return. Done.

The real challenge begins when you examine how fundamentally different these asset classes are—not just financially, but in their semantic models, lifecycles, and performance measurement characteristics.

The First Layer: Valuation Semantics Differ Fundamentally

Traditional securities live in a world of continuous pricing. A stock has a market price that updates every millisecond during trading hours. Valuation is not an event—it is a continuous state that can be sampled at any moment. The PriceCapturedEvent is merely a snapshot of market reality.

Private equity fund investments (LP positions) exist in a different temporal regime. As a Limited Partner, you do not have market prices for your fund positions. Instead, the General Partner (GP) provides quarterly Net Asset Value (NAV) statements showing your capital account balance. These are not observations of market consensus; they are calculated estimates combining mark-to-market holdings, discounted cash flow models for underlying portfolio companies, and GP-determined valuations. The LP must accept the GP's valuation methodology and timing.

Non-bankable assets occupy yet another valuation paradigm. A villa does not have a continuously observable price, nor does anyone send quarterly statements. Instead, valuation occurs through discrete appraisal events—perhaps annually for insurance purposes, when refinancing, or when contemplating sale. The appraisal methodology differs by asset type: real estate uses comparable sales and income approach, artwork requires specialist authentication and provenance verification, wine collections are valued by vintage and condition, yachts by age and maintenance history. The bounded context preserves these distinctions—an ArtworkAppraisalRecordedEvent carries different metadata (artist, provenance, condition report) than a RealEstateAppraisalRecordedEvent (square footage, location, comparable sales).

The Second Layer: Cash Flow Lifecycle Semantics Diverge

The Third Layer: Ownership and Beneficiary Models Differ

This creates a beneficiary type mismatch. For unified portfolio reporting, you need to answer: "Show me all cash flows for John Doe across all asset types." But for securities and PE, John's cash flows are associated with his accounts. For non-bankable assets, they are associated with John as an owner. The data models are structurally incompatible.

The Fourth Layer: Time and Performance Measurement Differ

• Bankable securities support time-weighted returns (TWR) because valuations are frequent and reliable. TWR isolates manager skill from investor timing.
• Private equity LP investments use Internal Rate of Return (IRR) and LP-specific metrics like MOIC (Multiple on Invested Capital), DPI (Distributions to Paid-In Capital), and RVPI (Residual Value to Paid-In Capital). PE fund positions do not have continuous valuations, so TWR is impossible to calculate meaningfully. LPs also need liquidity planning through cash flow projections to anticipate future capital calls and distributions.
• Non-bankable assets also typically use IRR (or Total Return if held long enough), but with additional complexity around irregular expenses and infrequent appraisals.

The Core Layer: Domain Purity vs. Unified Reporting

The problem is not that these differences exist. The problem is that they must coexist in two incompatible modes:

Visualizing the Semantic Mismatch

Here's the challenge in a single view. Three bounded contexts, each with pure domain terminology, but reporting needs a unified view:

The Traditional Approach (And Why It Accumulates Debt)

The conventional solution—implementing reporting as cross-context queries with manual semantic translation—works but creates maintenance burden:

• Every new cash flow type requires updating multiple report generators
• Every new valuation method requires extending the unified query logic
• The reporting layer becomes a tangled web of if-statements and context-specific branches
• Adding a fourth asset class requires revisiting every reporting component
• The complexity grows combinatorially

The Solution: Event-Driven Shared Semantic Layer

Shared Semantic Contracts

Two read models are defined in a shared kernel:

Important: These records are not domain aggregates. They are read models—derived views optimized for querying.

Event Projections Architecture: Preserving Domain Purity

The key insight: Domain events remain pure. Projections handle translation.

How Each Context Projects Events

Deals Context:

// BuyCapturedEvent → CashFlowRecord (FlowType=Buy, negative amount)
// SellCapturedEvent → CashFlowRecord (FlowType=Sell, positive amount)
// IncomeCapturedEvent → CashFlowRecord (FlowType=Income)
// PriceCapturedEvent → ValuationRecord (Method=Market, Confidence=High)

Private Equity LP Context:

// LP fund investments track commitment accounting from LP perspective
// LPCapitalCallCapturedEvent → CashFlowRecord 
//   (FlowType=Contribution, negative, reduces unfunded commitment)
// LPDistributionCapturedEvent → CashFlowRecord 
//   (FlowType=Distribution, positive, may be recallable)
// LPRecallableDistributionCapturedEvent → CashFlowRecord 
//   (FlowType=RecallableDistribution, marked as potentially reversible)
// LPManagementFeeCapturedEvent → CashFlowRecord 
//   (FlowType=Expense, FlowSubType=ManagementFee, typically 2% of commitment)
// LPCarriedInterestCapturedEvent → CashFlowRecord 
//   (FlowType=Expense, FlowSubType=CarriedInterest, typically 20% of profits)
// LPCapitalAccountNAVCapturedEvent → ValuationRecord 
//   (Method=NAV, Confidence=Medium, GP-provided quarterly statement)
// Used for calculating IRR, MOIC, DPI, RVPI and liquidity projections

Non-Bankable Assets Context (Preserving Asset-Specific Semantics):

// The NBA context preserves domain-specific terminology
// A villa is not the same as artwork, which is not the same as wine bottles

// Real Estate (Villa):
// VillaAcquiredEvent → CashFlowRecord (FlowType=Acquisition)
// PropertyTaxPaidEvent → CashFlowRecord (FlowType=Expense, FlowSubType=PropertyTax)
// PropertyMaintenanceEvent → CashFlowRecord (FlowType=Expense, FlowSubType=Maintenance)
// RentalIncomeReceivedEvent → CashFlowRecord (FlowType=Income, FlowSubType=Rent)
// RealEstateAppraisalRecordedEvent → ValuationRecord (Method=Appraisal, AssetType=RealEstate)

// Artwork:
// ArtworkAcquiredEvent → CashFlowRecord (FlowType=Acquisition)
// ArtworkConservationEvent → CashFlowRecord (FlowType=Expense, FlowSubType=Conservation)
// ArtworkStorageFeeEvent → CashFlowRecord (FlowType=Expense, FlowSubType=Storage)
// ArtworkAuthenticationEvent → CashFlowRecord (FlowType=Expense, FlowSubType=Authentication)
// ArtworkAppraisalRecordedEvent → ValuationRecord (Method=Appraisal, AssetType=Artwork)

// Wine Collection:
// WineBottlesAcquiredEvent → CashFlowRecord (FlowType=Acquisition)
// CellarStorageFeeEvent → CashFlowRecord (FlowType=Expense, FlowSubType=CellarStorage)
// BottlesConsumedEvent → No CashFlowRecord (consumption reduces quantity)
// WineCollectionAppraisalEvent → ValuationRecord (Method=Appraisal, AssetType=Wine)

// Yacht:
// YachtAcquiredEvent → CashFlowRecord (FlowType=Acquisition)
// YachtCrewSalaryEvent → CashFlowRecord (FlowType=Expense, FlowSubType=CrewSalary)
// YachtMaintenanceEvent → CashFlowRecord (FlowType=Expense, FlowSubType=Maintenance)
// CharterIncomeEvent → CashFlowRecord (FlowType=Income, FlowSubType=Charter)
// YachtAppraisalEvent → ValuationRecord (Method=Appraisal, AssetType=Yacht)

// Gift and Inheritance (all asset types):
// GiftRecordedEvent → No CashFlowRecord (ownership transfer without cash)
// InheritanceRecordedEvent → No CashFlowRecord (cost basis step-up without cash)

Unified Query Layer

Once projections populate the shared streams, a single query interface serves all reporting:

interface IPortfolioAnalyticsQuery {
    Task<IReadOnlyList<CashFlowRecord>> GetCashFlowsAsync(
        Guid? portfolioId, 
        Guid? beneficiaryRef, 
        SourceContext? sourceContext, 
        FlowType? flowType, 
        DateOnly? fromDate, 
        DateOnly? toDate, ...);
    
    Task<IReadOnlyList<ValuationRecord>> GetValuationsAsync(
        Guid? portfolioId, 
        Guid? assetRef, 
        SourceContext? sourceContext, 
        ValuationMethod? method, 
        DateOnly? fromDate, 
        DateOnly? toDate, ...);
    
    Task<decimal> GetPortfolioValueAsync(
        Guid portfolioId, 
        DateOnly asOfDate, ...);
}

All parameters are optional, enabling flexible queries:

• "All cash flows for Portfolio X across all contexts" → GetCashFlowsAsync(portfolioId: X)
• "Only PE contributions for Participation Y" → GetCashFlowsAsync(assetRef: Y, sourceContext: PE, flowType: Contribution)
• "NBA expense breakdown for Owner Z" → GetCashFlowsAsync(beneficiaryRef: Z, beneficiaryType: Owner, flowType: Expense)

Performance Measurement Becomes Context-Agnostic

var cashFlows = await _query.GetCashFlowsAsync(portfolioId);
var latestValuation = await _query.GetPortfolioValueAsync(
    portfolioId, 
    DateOnly.FromDateTime(DateTime.Today));
var irr = _irrCalculator.Calculate(cashFlows, latestValuation);

The IRR calculator does not care whether cash flows came from stock trades, capital calls, or yacht expenses. They are all CashFlowRecords with dates and amounts. The semantic translation happened upstream, in the projections.

Why This Works

The Result: Unified Analytics Without Domain Contamination

Once the projection layer is in place, portfolio analytics becomes remarkably simple:

Conclusion

Unified portfolio analytics is not limited by the ability to query multiple data sources or aggregate results. It is limited by the requirement to:

• Preserve domain semantic purity while providing normalized reporting semantics
• Handle fundamentally different valuation epistemologies
• Respect distinct cash flow lifecycle models
• Unify beneficiary types without contaminating domain models

The traditional approach—implementing reporting as cross-context queries with manual branching—works but scales poorly. Each new asset class multiplies maintenance burden. Each new report type requires context-specific logic.

In the end, you achieve the remarkable architectural feat of maintaining domain purity while providing unified reporting—without compromising either.

A triumph of event-driven design. A practical use of eventual consistency.