Apa yang sedang terjadi secara bisnis?
State mana yang berubah?
Invariant apa yang harus tetap benar?
Rule mana yang diterapkan?
Data mana yang menjadi source of truth?
Integration mana yang terdampak?
Failure apa yang mungkin terjadi?
Bagaimana recovery dan audit dilakukan?
Bagaimana saya mereview perubahan ini sebagai senior engineer?

Catalog defines what can be sold.
Configuration selects how it is sold.
Pricing defines commercial value.
Approval protects commercial authority.
Quote records the commercial proposal.
Order executes the accepted commercial intent.
Fulfillment realizes the service/product operationally.
Billing/charging monetizes the activated commitment.
Amend/cancel/renew keeps lifecycle continuous after initial sale.

A customer wants a business outcome.
The business offers a configured product under specific commercial terms.
The customer accepts or rejects the offer.
An accepted offer becomes an executable order.
The order coordinates downstream systems to deliver the product/service.
Billing/charging must reflect what was commercially accepted and operationally fulfilled.
Changes after initial sale must preserve auditability, correctness, and lifecycle continuity.

CPQ is the domain capability that helps users choose valid products, configure them correctly, calculate defensible prices, and produce a commercial proposal that can be approved, accepted, and converted into an executable order.

Quote management controls the lifecycle of the commercial proposal: draft, configuration, pricing, validation, submission, approval, acceptance, expiry, rejection, revision, and conversion readiness.

Order management controls the lifecycle of execution: capture, validation, decomposition, orchestration, dependency management, fulfillment tracking, fallout, retry, amendment, cancellation, completion, and reconciliation.

Quote-to-cash is the business lifecycle from commercial proposal to executable order, fulfillment, billing/charging, revenue recognition, and post-sale change.

In telco, CPQ/order management connects BSS commercial processes with OSS operational delivery through product/service/resource separation, catalog-driven behavior, fulfillment orchestration, inventory, provisioning, billing, and assurance.

When does quote become immutable?
When is pricing snapshotted?
When does approval become required?
When does approval become invalid?
When can quote be revised?
When can quote expire?
When can quote be converted to order?
What happens if catalog/pricing/customer/agreement changes after quote creation?

What is source of truth for order state?
Is state managed at order level, order item level, or both?
Can order be partially complete?
Can order be amended while in progress?
Can cancellation be accepted after downstream fulfillment started?
What is retryable and what requires manual intervention?
How does reconciliation repair mismatch?

What business concept is this?
Why does it exist?
Who uses it?
Who owns it?
Is it standard product behavior or customer-specific?

Which lifecycle does it belong to?
Which state does it start from?
Which state does it move to?
Which transitions are legal?
Which transitions are illegal?
Is it terminal, retryable, reversible, compensatable, or manual?

What must always remain true?
Where is the invariant enforced?
Can another API/event/batch/manual path bypass it?
Is the invariant tested?
Is violation observable?

Is this a product rule, pricing rule, approval rule, agreement rule, customer rule, operational rule, or integration rule?
Who owns the rule?
Can the rule change dynamically?
Is the rule versioned?
Is the rule auditable?

Is the data input, derived, copied, snapshotted, referenced, or replicated?
Is it current-state data or decision-time data?
Can it change after submission/approval/acceptance/order creation?
What is source of truth?

Which upstream systems provide data?
Which downstream systems consume data?
Is the exchange synchronous or asynchronous?
What happens on timeout/rejection/duplicate/out-of-order/missing event?
How is reconciliation done?

Who needs to see what happened?
What reason/actor/timestamp must be recorded?
Can support diagnose the issue?
Can operations repair it safely?
Can customer impact be explained?

A quote/order should reference a product offering that was valid for the relevant selling context.
A configured product should satisfy compatibility, eligibility, and mandatory option rules.
A product bundle should not contain invalid child combinations.
A catalog version change should not silently alter already accepted commercial records.
Catalog-driven decomposition should be traceable to the commercial product selected.

A quote should be associated with a valid customer/account/party context.
Billing account and service account semantics should not be mixed.
Customer-specific agreement terms should be applied consistently to pricing/eligibility.
Agreement-driven pricing should be auditable.
Customer hierarchy should not accidentally apply parent terms to invalid child accounts.

A submitted quote should have complete and valid pricing.
A price override should be traceable to actor, reason, and authority.
A discount above threshold should trigger required approval.
An approved quote should preserve the commercial basis that was approved.
A price recalculation should not silently change an already accepted quote.
Margin/profitability guardrails should not be bypassed through alternate flows.

A quote should not be accepted if expired, rejected, or missing required approval.
A quote revision should preserve the auditability of prior versions.
Quote-to-order conversion should use the accepted quote version.
Accepted quote data used for order creation should be stable or explicitly revalidated.
Quote documents should match stored commercial terms.

An order should not be created from an invalid or unauthorized quote.
An order item should preserve intended action: add, modify, disconnect, suspend, resume.
Order decomposition should not lose dependency relationships.
Order status should reflect item-level progress accurately enough for operations.
Cancellation should not ignore already-completed downstream work.
Amendment should not conflict with in-flight fulfillment without explicit handling.

Fulfillment should execute what was commercially accepted and order-validated.
Downstream rejection should be represented as recoverable or terminal business state.
Billing activation should align with fulfilled service/product state.
Manual fallout recovery should leave auditable trace.
Reconciliation should detect and repair cross-system mismatch.

Can we prevent it?
If not, can we detect it?
If detected, can we recover it?
If recovered, can we audit it?
If not recoverable, can we explain customer impact?

How do internal product offering/specification models map to TMF620?
Are bundle, relationship, eligibility, and versioning represented similarly?
Are extensions documented?
Does product catalog drive quote validation, pricing, and order decomposition?

How does internal quote lifecycle map to TMF648 Quote states?
Are quote items aligned with product offering references?
How are pricing, validity, approval, and revision represented?
Are extensions compatible with external consumers?

How does internal product order map to TMF622 ProductOrder?
How are order item actions represented?
How are item dependencies and milestones represented?
How does internal lifecycle differ from TMF622 status values?

How does internal customer/account/party model map to TMF629 resources?
Where are billing account and service account represented?
How is customer hierarchy handled?
What external system is source of truth?

How does fulfilled product state become product inventory?
How are active/disconnected/modified product instances represented?
How does product inventory relate to order history and billing?

How does product order decomposition map to service ordering?
Which system owns service order state?
How are service order failures propagated back to product order?
How is fallout represented?

Align where it improves interoperability and shared language.
Extend where product/customer reality requires it.
Diverge only intentionally, document why, and protect contract compatibility.

Is this external contract stable?
Is it aligned with TMF or internal API convention?
Does it expose internal implementation accidentally?
Are extension fields controlled?
Is backward compatibility preserved?

Does the model express business meaning?
Are invariants close to the domain object/rule owner?
Are lifecycle transitions explicit?
Are invalid states representable too easily?
Is customer-specific behavior isolated or leaking globally?

Is persistence optimized without distorting domain semantics?
Are snapshots and references clear?
Are historical records protected?
Does migration preserve business meaning?

Does the event represent a business fact?
Is it safe to replay?
Is it idempotent for consumers?
Does schema evolution preserve compatibility?
Can reconciliation rebuild state?

What business outcome is required?
Which actor performs it?
Which domain object changes?
Which lifecycle state is required before action?
Which lifecycle state results after action?
What validation is required?
What pricing/approval/agreement impact exists?
What catalog/customer/account context matters?
What external systems are involved?
What happens if external systems reject or timeout?
What should be auditable?
What should be observable?
What happens to existing data?
What regression scenarios are required?

Add field X.
Allow user to update Y.
Send event Z.
Call API A.

In state S, actor A may perform action X if conditions C are true.
The system transitions object O to state T, preserves invariant I, emits event E, records audit A, and handles failures F1/F2/F3.

What business behavior changed?
Is that behavior intended by requirement?
Is the change global or customer-specific?

Are new transitions introduced?
Are old transitions removed?
Are terminal states affected?
Are retry/manual states affected?
Are concurrent transitions safe?

Are pricing/approval/catalog/agreement/customer rules changed?
Is rule precedence clear?
Is rule ownership clear?
Is rule versioning/audit considered?

Are API/event schemas changed?
Is backward compatibility maintained?
Are consumers/producers updated?
Are missing/duplicate/out-of-order scenarios handled?

Is historical data affected?
Is migration needed?
Are snapshots/references preserved?
Are indexes/constraints aligned with business uniqueness?

What new failure modes exist?
Can they be detected?
Can they be retried or repaired?
Is manual intervention supported?
Is observability sufficient?

Can support explain what happened?
Can operations recover from partial failure?
Can product explain the business behavior?
Can customer impact be scoped?
Can engineering trace the event/API/data path?
Can finance/commercial audit pricing and approval?
Can downstream systems remain compatible?
Can old data still be interpreted correctly?

Which business decision is this feature encoding?
Which lifecycle state does this decision belong to?
What should be impossible after this change?
What behavior should be preserved for historical records?
What is the failure/recovery model?

This is complex because it changes accepted quote immutability, approval validity, order conversion behavior, and downstream billing alignment. We need to decide whether this creates a revision or mutates the existing quote.

The open decision is whether expired approved quotes can be converted. If yes, we need revalidation/repricing rules. If no, we need a blocked state and user-facing recovery path. My recommendation is to require explicit revision because it preserves auditability.

Can implement requested changes but relies on others to define domain behavior.

Can explain major flows and ask basic clarification questions.

Can review PR/design for business correctness, invariant safety, compatibility, and failure behavior.

Can own features end-to-end with product, architecture, QA, support, and downstream integration awareness.

Can improve the product/domain model itself: simplify lifecycle, clarify boundaries, reduce inconsistency, improve recovery, and make the system easier to reason about.

Part 001 — Domain foundation
Part 002 — CSG Quote & Order context
Part 003 — Quote-to-cash lifecycle
Part 004 — Product catalog and catalog-driven architecture
Part 005 — Customer, account, party, and agreement
Part 006 — Pricing, discounting, margin, and approval
Part 007 — Quote management
Part 008 — Order management
Part 009 — Fulfillment and downstream integration
Part 010 — Telco BSS/OSS mental model
Part 011 — TM Forum reference model
Part 012 — TM Forum Open APIs for quote and order
Part 013 — Domain modelling and bounded context
Part 014 — State machines and lifecycle invariants
Part 015 — Event-driven domain consistency
Part 016 — Business error and failure modelling
Part 017 — Requirement and user story analysis
Part 018 — Domain-aware PR and design review
Part 019 — Domain onboarding and 30/60/90-day plan
Part 020 — Domain mastery map for senior engineer

Vocabulary -> Lifecycle -> Catalog/Customer/Pricing -> Quote/Order -> Fulfillment/BSS/OSS -> TM Forum -> Modelling/State/Event/Failure -> Requirement/Review -> Onboarding/Mastery

When reading a requirement:
Find the lifecycle, invariant, rule, integration, failure, and audit implication.

When designing a change:
Make state transitions explicit and preserve business history.

When writing code:
Keep business meaning visible and enforce invariants at the right boundary.

When reviewing PR:
Review behavior, not only implementation.

When debugging production:
Ask which business fact the system got wrong.

When discussing product:
Frame ambiguity as options, consequences, and recommendation.

When learning domain:
Turn every bug, demo, PR, and story into a reusable mental model.

A domain-aware senior engineer does not merely ask, “Does the code work?”

They ask, “Does the system preserve the business truth it is responsible for?”