When designing a domain model for something like a Credit Line that changes over time, a solid approach is to keep a core CreditLine entity with just stable info (like its ID) and store all changing details (conditions, financial entities, contributions) in dated snapshots or Statements. This avoids duplicating static info and keeps complete history, letting you query the state at any date by picking the right snapshot. This matches your Option C and keeps the model clean and easy to maintain.

Another approach is Event Sourcing, where you store every change as an immutable event and rebuild the Credit Line’s state by replaying those events. This offers a detailed audit trail and no data duplication but adds complexity in querying and implementation.

For your case, Option C is usually simpler and practical unless you need fine-grained change tracking that Event Sourcing provides. Both are established patterns for managing evolving, versioned domain data.