Enterprise Architect interview questions

I would draw boundaries around business invariants and language rather than copy the current team or table structure.

• Order Management owns cart conversion, order states, and the stable order ID, but not card authorization or stock counts.
• Payments owns authorization, capture, and refund rules; Inventory owns reservations and available-to-promise quantities.
• Fulfillment starts from confirmed orders and reservations, then owns parcels, carriers, and delivery status.
• Cross-context changes travel through contracts such as OrderConfirmed and StockReserved, with no direct writes into another context's tables.

I would use the conflicting meanings of coverage as evidence that the three models should stay separate.

• Policy defines coverage as contracted limits and exclusions effective on a date.
• Billing cares about premium-bearing coverages and payment schedules, while Claims evaluates coverage against a loss event.
• I would run event-storming sessions with underwriters, billing specialists, and adjusters, then test each boundary against its own rules and change cadence.
• Integration contracts carry explicit terms such as PolicyCoverageSnapshot rather than a shared Coverage table.

I would let each bounded context keep the customer model needed for its decisions and share only stable identifiers and contracts.

• Customer Identity owns verified legal identity, KYC status, and party ID.
• Marketing owns consent, segments, and campaign preferences; Lending owns applicant, borrower, and credit relationship states.
• Context-specific projections consume identity events and store only the fields they need, with contract versions recorded.
• A party ID links records, but no domain may update another domain's customer representation directly.

I would make upstream influence, command ownership, and result publication explicit for every integration on the map.

• Pricing publishes a versioned Quote contract that Orders consumes as a customer-supplier relationship.
• Orders sends a versioned ReserveStock command to Inventory with the order ID, SKU, quantity, and idempotency key.
• Inventory owns the reservation invariant and publishes StockReserved or StockReservationRejected, while Orders stores the reservation ID and outcome.
• Shipping consumes the OrderReadyForDispatch published language and translates carrier-specific terms inside its own context.

I would place the anti-corruption layer at the Sales boundary so ERP concepts cannot leak into the new domain model.

• The layer translates SalesOrder and CustomerAccount into the ERP's document types, codes, and batch interfaces.
• It owns mapping tests against two supported ERP versions and quarantines records with unknown codes instead of silently defaulting them.
• Sales depends on its own port, while an adapter can later move from the ERP API to events without changing Sales rules.

I would allow a shared kernel only for a very small, jointly governed model whose semantic identity is proven.

• Currency, decimal rounding, and TaxJurisdiction value objects may qualify if both teams release them from one package and run the same conformance tests.
• Promotional eligibility and invoice tax calculation should remain separate because their rules and release cadence differ.
• The shared package needs named co-owners, semantic versioning, and a rule that breaking changes require both consumers to upgrade in one planned window.

I would build a many-to-many matrix between stable claims capabilities and the 12 applications that support them.

• Break Claims Management into intake, coverage validation, reserve calculation, fraud screening, settlement, and recovery.
• Map every application to every capability it supports and record its role, because one capability may use several applications and one application may support several capabilities without a forced primary.
• For each mapping, capture user groups, interfaces, annual run cost, lifecycle, criticality, and the specific business function provided.
• Validate the matrix with claims operations and application owners, then use overlaps and unsupported capabilities as evidence for investment decisions.

I would compare the three products by the capabilities they actually support, not by a generic CRM feature list.

• Map lead management, opportunity management, case handling, consent, and campaign execution to users, transaction volume, and required integrations.
• Separate intentional specialization, such as a service desk optimized for 20,000 cases per day, from duplicate account and contact storage.
• Consolidate only capabilities with equivalent requirements, then price migration, retraining, data cleansing, and lost specialist features in the decision.

I would score capabilities with a small, traceable set of business and technology measures.

• Rate business importance, customer pain, change demand, application health, and data quality on a defined 1-to-5 scale.
• Attach evidence such as checkout abandonment, warehouse exceptions, release lead time, and support cost rather than relying on workshop votes alone.
• Plot high-importance, low-health capabilities such as Returns Management first, and keep confidence and data date visible beside every score.

I would model the capabilities delivered by each transition state and make application dependencies explicit before sequencing waves.

• Order Capture cannot leave the legacy suite until pricing, customer identity, and tax contracts are available.
• Warehouse Allocation can move later if an adapter preserves the existing batch interface for six months.
• Each roadmap item names the capability outcome, predecessor, temporary integration, data migration, and retirement condition.
• Milestones are capability-based, such as 80% of orders allocated by the new service, rather than merely application installation dates.

I would use a transactional outbox so the order row and publish intent commit atomically in PostgreSQL.

• The same transaction inserts the order and an outbox record containing event ID, aggregate ID, type, schema version, and payload.
• Debezium CDC or a polling relay publishes the outbox record to Kafka, and a retention job archives or deletes processed rows only after the publish checkpoint and required replay or audit window.
• Consumers remain idempotent because the relay can publish twice after a crash.
• I would monitor unpublished row age and alert if the oldest item exceeds the agreed 60-second delivery objective.

I would make the event ID or business operation key part of the same transaction as the accounting entry.

• Store the processed event ID under a unique constraint in the transaction that creates the ledger entry.
• If capture can be retried with different event IDs, use merchant ID plus payment ID plus operation type as the stable idempotency key.
• A duplicate becomes a successful no-op, while a reused key with a different amount is rejected and surfaced for investigation.
• Keep the idempotency evidence linked to the ledger entry for the ledger's statutory and business retention period, even when the broker replay window is shorter.

I would automate compatibility rules in team pipelines and reserve review for semantic or breaking changes.

• Register Avro or Protobuf subjects by domain and event type, with backward compatibility as the default.
• Producers can add optional fields with defaults, but renames, type changes, and removals fail CI against registered versions.
• Each schema carries an owning team, purpose, data classification, and deprecation date in the catalog.
• A contract test runs representative old consumers against the new producer schema before release.

The contract should carry a stable business fact and enough metadata to process it safely, but not expose the order service's internal model.

• The payload includes order ID, confirmation time, customer reference, line identifiers, quantities, currency, and confirmed totals.
• The envelope includes event ID, occurred-at time, producer, schema version, correlation ID, and trace context.
• Billing and Fulfillment own separate projections and must not rely on fields marked internal or reconstruct an order aggregate.
• The Orders team owns meaning and compatibility, while consumers register usage so removals have a known blast radius.

I would use choreography for this four-domain Orders, Payments, Inventory, and Shipping flow only while it stays within explicit complexity and ownership limits.

• Orders emits OrderConfirmed, Payments emits PaymentAuthorized, Inventory emits StockReserved, and Shipping emits DispatchScheduled or DispatchRejected without a central coordinator.
• Each participant owns its local transaction and publishes through an outbox.
• A correlation ID and a process projection let the named order-flow owner measure the end-to-end completion SLO.
• I would introduce an orchestrator when the flow exceeds four participating domains, adds more than two timers or compensation branches, or no single owner can meet the end-to-end SLO.

I would use an orchestrated saga because the process has explicit sequencing, timers, and recovery decisions.

• A LoanApplication process manager stores state and issues commands to Identity, Credit, Documents, and Accounts.
• Every command has a correlation ID, idempotency key, deadline, and expected reply type.
• The orchestrator persists transitions before sending the next command and can resume after a restart.
• Domain services still own their local transactions; the orchestrator owns only process state, not their business data.

I would define compensation as explicit business actions because distributed work cannot be rolled back like one database transaction.

• If hotel reservation fails, issue CancelFlightReservation and VoidPaymentAuthorization with their original operation IDs.
• Record whether each action is reversible, time-limited, fee-bearing, or manual, since a ticket may become nonrefundable.
• Retries use idempotency keys and bounded backoff, then move unresolved cases to an operations queue.
• The saga ends in Completed, Compensated, or ManualResolution, so partial outcomes remain visible.

I would use CQRS if a separately optimized read projection removes real pressure without duplicating the write rules.

• Keep commands and invariants in the transactional model, then project committed changes into Elasticsearch for search.
• Publish the expected freshness, for example p95 under five seconds, and show users when a just-written item is still indexing.
• Rebuild projections from a retained change stream and version the projector so deployments can run old and new indexes in parallel.
• I would not split command and query services if indexed SQL already meets the target with less operational cost.

I would choose event sourcing only when the complete decision history is a core domain requirement, not just because events are already used.

• Subscription plan changes, pauses, credits, and renewals can form an auditable stream from which billing state is derived.
• The design needs immutable event semantics, snapshotting for long streams, upcasters for old versions, and tested projection rebuilds.
• I would reject it for reference data or simple CRUD where a temporal table and audit log meet the need.
• Privacy erasure and correction rules must be designed before storing personal fields in an immutable stream.

I would rely on Kafka ordering only within a partition and key records by the actual consistency boundary.

• Warehouse ID plus SKU keeps ReservationCreated, StockReceived, and ReservationReleased for one stock aggregate in the same partition.
• A consumer processes each assigned partition serially, or uses a key-aware executor that preserves per-key order while different keys run concurrently.
• Offsets are committed only after all lower offsets in that partition complete successfully, so a failed record pauses safe progress instead of being skipped.
• Aggregate sequence numbers detect gaps, and a peak-load test verifies that a hot SKU does not exceed one partition's throughput.