Domain Model
KBP owns no business data. Every business object an agent sees or changes is a read model of an
external system of record. This page is therefore a logical data model, the static alternative to a
DDD domain model that arc42 allows: it names the business objects, how they relate and which system
is authoritative for each. The business processes that use them are described in the
Use Cases;
the complete attribute lists are the code in EnBW.Vertrieb.Websites.KBP.Core/Entities.
An aggregate on this page means the business objects that one system of record owns. It is not a DDD consistency boundary: KBP enforces no invariants across these objects.
| Aggregate | Key business objects | System of record | Used by feature areas |
|---|---|---|---|
| Customer and identity | Customer, Identity, Owner | Customer Identity (CIM), EnWiCore | all |
| Master data | Personal data, addresses, contact data, payment data | CMDM | Customer account, contracts, order capture |
| MyEnergyKey account | Portal account, deletion status | Auth0, Customer Identity Linking Process | Customer account |
| E-mobility debitor | Debitor, e-mobility account | E-Mobility Billing | Entry points, account data (mobility+) |
| Contracts and consumption | Contract, tariff, meter, deposit plan, lock, change order | EnWiCore, Commodity Layer, Dynamics Sales | Contracts, tariff change, receivables |
| Offers and orders | Offer, order | ComV3 (COMtrol), EnWiCore, Bundle Lifecycle Management | Order capture, tariff change, relocation |
| Financial account | Accounting record, payment, payment plan | APA | Account data |
| Relocation | Relocation process | Commodity Layer | Relocation |
| Receivables tasks | Task (Auftrag) with state history and notes | ZAuV / Digital Layer | Receivables management, legal department |
| Marketing permissions | Consent per channel and topic | Permission Service | Marketing permissions, order capture |
| Telephone PIN | Service PIN | PIN Service | Telephone PIN |
| Next Best Action and content | Customer profile, recommendation, alert | MXO, Contentful | NBA, notifications |
Relationships between aggregates
Aggregates
Customer and identity. Customer is the root of an agent session. Identity links one person
across all systems and holds the id each system needs; customers that the central identity service
cannot resolve are marked as such. An Owner is an EnWiCore customer record used by owner management.
Master data (CMDM). Personal data, addresses, e-mail addresses, phone numbers and payment data are versioned. Every entry records which contracts and tenants use it, and a change reason and reporter.
Contracts and consumption (EnWiCore). A commodity contract (electricity, gas, heat and others) carries its tariff history with price components, meters, deposit plan, dunning and payment locks, documents and the change order that started supply. Smart-meter installation progress comes from Dynamics Sales.
Offers and orders (ComV3). Offers come from ComV3. An order placed in ComV3 is read back from EnWiCore until it becomes a contract.
Financial account (APA). Accounting records (Belege) per contract, the payments that settle them, and payment plans (Ratenzahlung) or deferrals (Stundung) over them.
Relocation (Commodity Layer). A relocation combines the agent’s input with the Commodity Layer’s validation of it and the contract facts that limit it, such as the possible move-in and move-out dates. It ends in a new order or a termination.
Receivables tasks (ZAuV). One generic task shape for all task types, for example dunning, debt collection or disconnection. Each task has a history of state changes and notes. The states are ZAuV state-machine keys and are described per task type in the receivables use cases.
Marketing permissions (Permission Service). Consent per channel and topic, and the recorded activity (consent, revocation, confirmation) with the consent text version that was shown.
Telephone PIN, MyEnergyKey, e-mobility, NBA. The service PIN is only ever checked for single digits. The MyEnergyKey account carries the status of its deletion process. The MXO customer profile has no fixed schema and is handled as an exception to typed integration contracts, see ADR 9.4.
Key states
| Business object | States |
|---|---|
| Master data entry | Unconfirmed, Valid, Invalid, Removed |
| Customer | Active, Prospective, Old |
| Contract delivery | FutureActive, Active, Terminated, Ended, Cancelled, ConfirmationNetworkOperatorMissing |
| Order (ComV3) | Opened, Confirmed, Completed, Failed |
| Accounting record | Offen, Faellig, InStundung, InRatenzahlung, Ausgeglichen, Storniert |
| Relocation process | Open, InProgress, Relocated, Cancelled, CancelledByThirdParty, Excluded |
| Consent | ConfirmationPending, Confirmed, Revoked, Refused |
| MyEnergyKey deletion | NoDeletionRequested, DeletionPending, DeletionDone |
Maintenance
Update this page when a business object, relationship or state is added or removed, or when an aggregate moves to another system of record (for example master data from EnWiCore to CMDM). Also update the domain map in that case. Attribute changes need no update here.