Chosing identies for DDD based journaling system - domain-driven-design

Question

Related to this question, I am modelling the identities for a trade logging/management system.
It will be multi-tenanted with users only able to see tenants they have been given rights to, so I have a partition key called TenantId.
The other fields are as follows for a Trade that has taken place:
internal class Trade : ValueObject
{
public Account Account { get; init; } // See below - belongs to a Tenant / Account / Broker
public TradeId TradeId { get; init; } // Unique tradeId (string i.e. 0000d695.234242.01.01)
public UserId UserId { get; init; } // A user potentially could create trades in other tenants, with appropriate claims/roles as part of an access control context.
public Contract Contract { get; init; } // Exact same contract can be traded on many different brokers
public string Exchange { get; init; }
public string BrokerContractId { get; init; }
public string BucketName { get; init; }
public decimal Position { get; init; }
public double Average { get; init; }
public DateTime Timestamp { get; init; }
protected override IEnumerable<object> GetEqualityComponents()
{
yield return Account;
yield return TradeId;
}
}
I don't see a trade as an entity as such, as there are no operations to perform - it is merely a log entry. I use the following identities to identify it:
public class TradeId : Identity
{
public TradeId(string fillId) : base(fillId) { } // Must be unique for each and every fill.
}
public class UserId : Identity
{
public UserId(string username) : base(username) { }
}
I have an account, which is unique to a broker, and coupled strongly as part of a tenant (one tenant would never see anothers brokerage account):
public class AccountId : Identity
{
public AccountId(string accountNumber) : base(accountNumber) { }
}
// An account belongs to broker, and within a tenant (that can have multiple accounts).
public class Account : EntityWithCompositeId
{
public AccountId AccountId { get; init; }
public TenantId TenantId { get; init; }
public BrokerId BrokerId { get; init; }
public Account(TenantId tenantId, BrokerId brokerId, AccountId accountId)
{
TenantId = tenantId;
BrokerId = brokerId;
AccountId = accountId;
}
protected override IEnumerable<object> GetIdentityComponents()
{
yield return TenantId;
yield return BrokerId;
yield return AccountId;
}
}
Question 1: I have noticed that if TenantId is part of the AccountId (since an account cannot exist without the Tenant), it would save me adding TenantId in all my entitities - are there any disadvantages to this?
Question 2: Given the below contract, even if i did include unique data such as FIGI composite ID, regardless of it being unique, it is still a value object as it wouldn't ever have business logic inside - is this the right school of thought?
// The same contract can exist on more than one broker.
public class Contract : ValueObject
{
public string Symbol { get; init; }
public string Currency { get; init; }
public override string ToString() => Symbol;
protected override IEnumerable<object> GetEqualityComponents()
{
yield return Symbol;
yield return Currency;
}
}

Answer 1

I have started to flesh this out, an AccountID is ok as the three components form the identity:
// An account belongs to broker, and within a tenant (that can have multiple accounts).
public class AccountId : ValueObject
{
public string Id { get; init; }
public TenantId TenantId { get; init; }
public BrokerId BrokerId { get; init; }
public AccountId(TenantId tenantId, BrokerId brokerId, string id)
{
TenantId = tenantId;
BrokerId = brokerId;
Id = id;
}
protected override IEnumerable<object> GetEqualityComponents()
{
yield return TenantId;
yield return BrokerId;
yield return Id;
}
}
Executions are value objects, with no lifetime as they cannot exist outside of an account:
public class FillDetail : ValueObject
{
public string FillId { get; init; }
// Must be unique for each and every fill.
public FillDetail(string fillId) => FillId = fillId;
protected override IEnumerable<object> GetEqualityComponents()
{
yield return FillId;
}
}
public class Execution : ValueObject
{
public FillDetail FillDetail { get; init; }
public UserId UserId { get; init; } // A user potentially could create trades in other tenants, with appropriate claims/roles.
public Contract Contract { get; init; }
public string Exchange { get; init; }
public string BrokerContractId { get; init; }
public string BucketName { get; init; }
public decimal Size { get; init; }
public double Price { get; init; } // The execution price, excluding commissions.
public DateTime Timestamp { get; init; }
public Action Action { get; init; }
public bool IsForcedLiquidation { get; init; }
public Side Side { get; init; }
public Liquidity Liquidity { get; init; }
public FillDetail? Correction { get; init; }
protected override IEnumerable<object> GetEqualityComponents()
{
yield return FillDetail;
yield return UserId;
yield return Contract;
yield return Exchange;
yield return BrokerContractId;
yield return BucketName;
yield return Size;
yield return Price;
yield return Timestamp;
yield return Action;
yield return IsForcedLiquidation;
yield return Side;
yield return Liquidity;
if (Correction != null) yield return Correction;
}
}
The account is a Entity as it evolves over time, and would have business logic to for example:
Calculate P+L when executions are entered on the ledger
Prevent trades from taking place if current positions (derived from the execution log) are open, or additional orders, hedges etc.
This logic would belong in the Account:
public sealed class Account : Entity
{
public AccountId AccountId { get; init; }
readonly List<Execution> executions = new();
public void LogExecution(Execution execution)
{
// TODO: Check if this execution already exists, if so ignore it.
this.executions.Add(execution);
// This is where we would scan list of prior trades, calculate open positions, P+L etc.
}
public void PlaceOrder(Contract contract)
{
// We could have limit of no more than 10% of account balance allocated to any one position.
}
public IEnumerable<Execution> GetExecutions()
{
throw new NotImplementedException();
}
protected override IEnumerable<ValueObject> GetIdentityComponents()
{
yield return AccountId;
}
}
I think this is more likely a better model, whilst I now have concerns on the massive execution log (and managing that performance) however I will save that for a further question.
Feel free to provide your own answers, pointers much appreciated.