Part 041 — Bounded Contexts, Aggregates, and Team Ownership

Positioning

Enterprise CPQ dan Quote-to-Order tidak gagal hanya karena salah memilih database atau framework.

Banyak kegagalan berasal dari boundary yang kabur:

• Catalog dan Inventory menggunakan object Product yang sama;
• Quote dan Product Order berbagi lifecycle status;
• Pricing menjadi utility tanpa owner;
• Approval tertanam di Quote aggregate;
• Billing menginterpretasikan ulang accepted price;
• dan satu team bertanggung jawab atas terlalu banyak domain semantics.

Ketika boundary tidak eksplisit, perubahan kecil memerlukan koordinasi lintas puluhan services.

Core thesis: bounded context harus dibentuk berdasarkan semantic authority dan change cadence, bukan sekadar tabel, microservice, atau organisasi saat ini. Aggregate menentukan transactional consistency boundary; team ownership menentukan siapa yang berhak mengubah model dan kontraknya.

1. Domain

Domain adalah area bisnis yang memberikan value dan memiliki rules, vocabulary, serta decisions.

Dalam CPQ/Quote-to-Order, domain luas dapat mencakup:

• Catalog;
• Product Configuration;
• Pricing;
• Quote;
• Approval;
• Agreement;
• Product Order;
• Fulfillment;
• Inventory;
• Billing;
• dan Revenue.

2. Subdomain

Subdomain adalah bagian lebih kecil dari domain.

Kategori umum:

• Core;
• Supporting;
• Generic.

3. Core Subdomain

Core subdomain memberi competitive differentiation.

Contoh potensial:

• complex product configuration;
• telecom pricing;
• order decomposition;
• or customer-specific commercial orchestration.

Core status harus diverifikasi terhadap strategi organisasi.

4. Supporting Subdomain

Mendukung bisnis tetapi bukan pembeda utama.

Contoh:

• proposal document generation;
• approval assignment;
• account eligibility.

5. Generic Subdomain

Masalah umum yang dapat menggunakan platform/produk standar.

Contoh:

• notification;
• identity;
• object storage;
• audit transport.

6. Bounded Context

Bounded Context adalah boundary di mana:

• model;
• language;
• invariants;
• data authority;
• dan APIs

memiliki meaning yang konsisten.

7. Context Is Not a Microservice

Satu bounded context dapat diimplementasikan sebagai:

• modular monolith module;
• one service;
• several services;
• or service plus workers/read models.

8. Microservice Is Not Automatically a Context

Service dapat hanya menjadi:

• adapter;
• projection;
• workflow worker;
• atau technical utility.

9. Context Is Not a Database

Shared database tidak otomatis berarti satu context.

Separate database juga tidak otomatis berarti separate contexts.

10. Context Is Not a Team

Satu team dapat memiliki beberapa context kecil.

Satu context besar dapat membutuhkan beberapa teams, tetapi authority harus tetap jelas.

11. Semantic Boundary

Boundary muncul ketika istilah yang sama memiliki meaning berbeda.

Example:

Product in Catalog
Product in Quote
Product in Product Order
Product in Inventory

12. Catalog Product

Definition or specification.

13. Quote Product

Customer-specific configured commercial candidate.

14. Ordered Product

Requested target state and action.

15. Inventory Product

Actual installed customer product instance.

16. Same Word, Different Models

Do not force one canonical class across all contexts.

17. Ubiquitous Language per Context

Each context owns its own precise vocabulary.

18. Translation Boundary

Context integration requires translation between models.

19. Anti-Corruption Layer

ACL protects one context from another context’s model.

20. Context Map

A Context Map documents:

• contexts;
• relationships;
• upstream/downstream;
• contract ownership;
• and integration style.

21. Candidate Contexts

Representative candidates:

• Catalog;
• Configuration;
• Qualification;
• Pricing;
• Quote;
• Approval;
• Proposal;
• Agreement;
• Product Order;
• Fulfillment Planning;
• Orchestration;
• Product Inventory;
• Billing Handoff;
• Billing;
• Party/Account;
• Tax;
• and Revenue.

22. Catalog Context

Owns:

• offering/specification definitions;
• relationships;
• characteristic definitions;
• lifecycle;
• and publication/versioning.

23. Configuration Context

Owns:

• configuration session;
• selected values;
• constraint evaluation;
• and configuration completeness.

24. Qualification Context

Owns:

• eligibility;
• availability;
• serviceability;
• and qualification evidence.

25. Pricing Context

Owns:

• price selection;
• evaluation;
• discount resolution;
• and price snapshots.

26. Quote Context

Owns:

• Quote aggregate;
• revisions;
• accepted commercial composition;
• and Quote lifecycle.

27. Approval Context

Owns:

• approval request;
• policy;
• authority;
• decisions;
• and reapproval evidence.

28. Proposal Context

Owns:

• templates;
• clause selection;
• rendering;
• artifact identity;
• and presentation evidence.

29. Agreement Context

Owns:

• accepted contractual commitment;
• Agreement items;
• amendments;
• and effective periods.

30. Product Order Context

Owns:

• Product Order;
• Order Items;
• action semantics;
• requested dates;
• and Order lifecycle.

31. Fulfillment Planning Context

Owns:

• decomposition;
• Plan;
• units;
• feasibility;
• capacity;
• and scheduling.

32. Orchestration Context

Owns:

• dependency progression;
• attempts;
• timers;
• barriers;
• retries;
• and process recovery.

33. Product Inventory Context

Owns:

• installed Product;
• lifecycle;
• effective history;
• and pending change reservations.

34. Billing Handoff Context

Owns:

• charge activation contract;
• handoff process;
• mapping;
• and reconciliation.

35. Billing Context

Owns:

• Billing Account;
• Billing Charge;
• usage rating;
• invoice;
• and Billing adjustments.

36. Party and Account Context

Owns:

• party identity;
• customer/account;
• contacts;
• roles;
• and legal entities.

37. Tax Context

Owns:

• tax determination;
• jurisdiction;
• category;
• exemption;
• and authoritative tax result.

38. Revenue Context

Owns:

• performance obligations;
• allocation;
• recognition schedule;
• and accounting events.

39. Shared Kernel

Two contexts share a small model intentionally.

40. Shared Kernel Risk

Changes require synchronized governance.

Keep it very small.

41. Customer–Supplier Relationship

Upstream defines model/contract.

Downstream consumes.

42. Conformist

Downstream adopts upstream model without translation.

43. Anti-Corruption Layer Relationship

Downstream translates and protects its model.

44. Open Host Service

Context exposes a stable service/API for many consumers.

45. Published Language

A shared integration schema or protocol.

46. Partnership

Two contexts co-evolve with close coordination.

47. Separate Ways

No integration; duplicated capability accepted.

48. Context Relationship Choice

Choose based on:

• semantic distance;
• ownership;
• coupling;
• strategic importance;
• and consumer count.

49. Upstream

Context that controls model/contract consumed downstream.

50. Downstream

Context that adapts to upstream contract.

51. Upstream Responsibility

Provide:

• stable contract;
• versioning;
• deprecation;
• and impact communication.

52. Downstream Responsibility

Protect local invariants and avoid leaking upstream internals.

53. Partnership Risk

Can become permanent coordination tax.

54. Published Language Example

A Product Order API schema can be a published language.

55. Canonical Model Risk

A global canonical model often becomes:

• bloated;
• politically owned;
• slow to change;
• and semantically ambiguous.

56. Minimal Integration Model

Prefer purpose-specific contracts.

57. Context Boundary Signals

Signals include:

• different lifecycle;
• different authority;
• different consistency needs;
• different security;
• different scale;
• different change cadence;
• and different team expertise.

58. Lifecycle Boundary

Quote lifecycle differs from Product Order lifecycle.

59. Authority Boundary

Pricing owns calculation; Quote stores accepted snapshot.

60. Consistency Boundary

Acceptance must be atomic within Quote/Offer context, not across Billing.

61. Security Boundary

Margin and approval comments need different access than customer-facing proposal.

62. Scale Boundary

Catalog reads and Order execution have different workload.

63. Change-Cadence Boundary

Tax rules may change independently from Product configuration.

64. Technology Boundary

Technology alone is weak reason, but specialized engines may reinforce real domain boundaries.

65. Context Cohesion

Context should contain concepts that change together.

66. Context Coupling

Excess cross-context synchronous calls reduce autonomy.

67. Temporal Coupling

Operation requires multiple contexts available simultaneously.

68. Semantic Coupling

One context depends on internal meaning of another.

69. Deployment Coupling

Changes require coordinated release.

70. Data Coupling

Contexts share tables or mutable records.

71. Operational Coupling

Failure/latency in one context blocks unrelated flows.

72. Coupling Budget

Treat cross-context dependencies as limited budget.

73. Aggregate

Aggregate is consistency boundary around entities/value objects.

74. Aggregate Root

Only root receives commands and protects invariants.

75. Aggregate Is Not Object Graph

Do not load every related domain entity into one aggregate.

76. Aggregate Is Not Transaction Script

It should model business invariants and decisions.

77. Aggregate Is Not Context

One context contains one or more aggregates.

78. Aggregate Size

Prefer small aggregates that protect true invariants.

79. Large Aggregate Symptoms

• high lock contention;
• large transaction;
• heavy serialization;
• and unrelated updates conflict.

80. Tiny Aggregate Symptoms

• invariants spread across services;
• excessive choreography;
• and eventual consistency where atomicity is required.

81. Aggregate Boundary Question

Ask:

What must be consistent immediately after one command commits?

82. Quote Aggregate Candidate

May own:

• Quote identity;
• revision;
• items;
• lifecycle;
• total references;
• and acceptance guards.

83. Quote Item Entity

Identity persists inside Quote.

84. Quote Price Snapshot

May be value/object reference depending size and ownership.

85. Approval Request Separate Aggregate

Avoid embedding entire approval workflow in Quote.

86. Proposal Separate Aggregate

Artifact lifecycle is separate.

87. Product Order Aggregate Candidate

May own:

• Order header;
• item identities;
• action;
• relationships;
• and lifecycle.

88. Large Product Order Partitioning

Header and item partitions may be separate aggregates with finalization barrier.

89. Product Inventory Aggregate

Often one Product per aggregate.

90. Agreement Aggregate

Could be Agreement plus Agreement Items, with partitioning for very large contracts.

91. Fulfillment Plan Aggregate

May own graph metadata while node partitions are separate.

92. Fallout Case Aggregate

Owns exception lifecycle and recovery decisions.

93. Idempotency Record

Technical consistency record, not necessarily domain aggregate.

94. Value Object

Immutable concept defined by value.

Examples:

• Money;
• Quantity;
• EffectivePeriod;
• Currency;
• ProductReference;
• and PriceComponentReference.

95. Entity

Has stable identity over time.

96. Domain Service

Coordinates domain operation not naturally owned by one entity.

97. Application Service

Orchestrates use case and transaction.

98. Policy

Encapsulates decision rule.

99. Repository

Loads/persists aggregates.

100. Domain Event

Records meaningful fact after state change.

101. Integration Event

Public contract for other contexts.

102. Domain Event versus Integration Event

Internal event may be rich/local.

Integration event should be stable/minimal.

103. Aggregate Reference

Prefer identity reference to another aggregate.

104. Cross-Aggregate Invariant

Cannot always be atomic.

Use:

• process manager;
• reservation;
• policy;
• or eventual consistency with compensation.

105. Reservation Pattern

Reserve scarce or exclusive domain scope.

106. Finalization Barrier

Checks cross-partition/cross-aggregate state before commit transition.

107. Snapshot Pattern

Copy immutable external evidence into local context.

108. Reference Pattern

Store external identity/version and fetch when needed.

109. Snapshot versus Reference

Choose based on:

• historical reproducibility;
• freshness;
• size;
• and authority.

110. Historical Snapshot

Accepted price, terms, and product labels often need snapshot.

111. Live Reference

Current customer contact may be referenced/live for operational communication.

112. Mixed Snapshot

Store essential immutable fields plus authoritative reference.

113. Aggregate Consistency

Inside aggregate:

• synchronous;
• transactional;
• immediate.

Across aggregates:

• asynchronous/eventual where possible.

114. Transaction Boundary

One command should usually modify one aggregate.

115. Multi-Aggregate Transaction

May be acceptable inside one database/context when true atomic invariant requires it.

116. Distributed Transaction

Avoid pretending distributed contexts share local transaction semantics.

117. Process Manager

Coordinates multiple aggregates/contexts over time.

118. Saga

Sequence of local transactions and compensations.

119. Choreography

Contexts react to events.

120. Orchestration

Coordinator controls progression.

121. Process Ownership

One context/team must own long-running process semantics.

122. Dual Ownership Smell

Quote and workflow engine both decide Quote state.

123. State Ownership

For every state, define one authority.

124. Data Ownership

For every field, define one authoritative context.

125. Rule Ownership

For every rule, define one context/team.

126. Event Ownership

Publisher owns event semantics.

127. Contract Ownership

Provider owns API/event contract lifecycle with consumer obligations.

128. Team Ownership

Team responsible for:

• domain model;
• code;
• data;
• runtime;
• contracts;
• operations;
• incidents;
• and evolution.

129. You Build It, You Run It

Useful principle when matched with domain authority and operational capability.

130. Team Topology

Common team types:

• stream-aligned;
• platform;
• enabling;
• complicated-subsystem.

131. Stream-Aligned Team

Owns end-to-end value stream slice or domain capability.

132. Platform Team

Provides reusable internal capabilities.

133. Enabling Team

Helps teams adopt architecture, security, observability, or domain techniques.

134. Complicated-Subsystem Team

Owns specialized engine requiring deep expertise.

Potential examples:

• pricing engine;
• optimization;
• tax;
• rating.

135. Team Cognitive Load

A team cannot own unlimited contexts and technologies effectively.

136. Context-to-Team Alignment

Prefer one stable team owning one or a few cohesive contexts.

137. One Context, Many Teams

Possible for scale, but split by clear subdomain/modules.

138. Many Contexts, One Team

Possible for small scope but watch cognitive load and conflicting priorities.

139. Shared Ownership Smell

“Everyone owns it” often means no one owns it.

140. Component Ownership versus Domain Ownership

Owning a library is not the same as owning a business capability.

141. Run Ownership

Who handles alerts and incidents?

142. Data Stewardship

Who approves schema/data corrections?

143. Contract Stewardship

Who approves breaking changes?

144. Product Ownership

Who prioritizes capability outcomes?

145. Architecture Ownership

Who decides boundaries and cross-context patterns?

146. RACI

Can clarify:

• Responsible;
• Accountable;
• Consulted;
• Informed.

147. RACI Limitation

RACI does not replace clear decision authority.

148. Context Owner

A named team/accountable role for:

• semantics;
• roadmap;
• contract;
• and operations.

149. Consumer Registry

Track consumers of APIs/events.

150. Consumer Dependency

Provider should know critical consumers before changing contract.

151. Ownership Metadata

Can be represented in:

• service catalog;
• repository metadata;
• API catalog;
• dashboards;
• and runbooks.

152. Ownership Fields

Examples:

contextOwner
serviceOwner
dataOwner
onCall
productOwner
securityContact
contractContact

153. Ownership Drift

Organizations change.

Metadata must be maintained.

154. Orphan Service

Service without active owner is production risk.

155. Orphan Data

Table/topic/schema without owner.

156. Orphan Contract

API/event without responsible provider.

157. Organizational Boundary

Conway’s Law suggests system architecture mirrors communication structure.

158. Inverse Conway Maneuver

Shape teams to support desired architecture.

159. Coordination Cost

Cross-team synchronous dependencies create planning and incident cost.

160. Team API

A team exposes stable contracts and support expectations.

161. Internal Platform Boundary

Platform should provide capabilities, not seize domain decisions.

162. Platform Golden Path

Can standardize:

• service bootstrap;
• observability;
• security;
• deployment;
• idempotency;
• and event publishing.

163. Platform Anti-Pattern

Central platform team becomes approval bottleneck for every domain change.

164. Shared Library Boundary

Good for:

• technical primitives;
• telemetry;
• security clients;
• and generated contracts.

Avoid sharing domain entities.

165. Shared Domain Library Risk

Creates compile-time coupling and coordinated releases.

166. Code Ownership

Repository ownership should align with context boundaries.

167. Monorepo

Can still preserve context boundaries using modules, ownership, and dependency rules.

168. Polyrepo

Does not guarantee independent contexts.

169. Dependency Rule

Context module should depend only on allowed contracts.

170. Architecture Test

Automate forbidden package/module dependencies.

171. Database Ownership

Each context should own writes to its data.

172. Shared Database Read

May be transitional but creates coupling.

173. Shared Database Write

High-risk; destroys authority.

174. Reporting Database

Read-only integration/projection can aggregate across contexts.

175. Data Warehouse/Lake

Analytics copy, not transactional authority.

176. CDC Boundary

CDC can replicate changes but often lacks domain semantics.

177. Event Boundary

Domain/integration events communicate meaningful facts.

178. API Boundary

Synchronous request/response for immediate use cases.

179. File Boundary

Batch/legacy integration may use files with explicit schema/version.

180. Context Contract

Every boundary should define:

• semantics;
• ownership;
• versioning;
• consistency;
• error behavior;
• and security.

181. Synchronous Call Criteria

Use when:

• caller needs immediate answer;
• operation is bounded;
• authority is online;
• and failure can be handled.

182. Asynchronous Criteria

Use when:

• long-running;
• decoupling needed;
• side effect durable;
• or eventual consistency acceptable.

183. Query versus Command

Queries do not request state changes.

Commands express intent.

184. Command across Context

Provider validates its own invariants.

185. Event across Context

Consumer must tolerate duplicates and lag.

186. Query Model

Purpose-specific read models can combine data.

187. Composite UI

UI may aggregate multiple contexts without creating a new authority.

188. Backend for Frontend

Can compose context APIs for a channel.

189. BFF Boundary

Should not become hidden domain monolith.

190. Workflow Boundary

Workflow coordinates, but domains decide local rules.

191. Rules Engine Boundary

Rules engine executes policy but context owns semantics and versions.

192. Context Testing

Test local model/invariants independently.

193. Contract Testing

Test provider and consumer compatibility.

194. Integration Testing

Test translations and consistency behavior.

195. End-to-End Testing

Use selectively for critical value streams.

196. Architecture Fitness Function

Automated checks that preserve boundaries.

Examples:

• no shared writes;
• no direct dependency on forbidden module;
• every event has owner/schema/version;
• and every service has on-call metadata.

197. Boundary Metrics

Possible metrics:

• number of synchronous dependencies;
• change failure caused by upstream;
• contract breakages;
• shared-table access;
• and deployment coupling.

198. Context Health

Track:

• incident rate;
• API latency;
• event lag;
• data quality;
• and ownership completeness.

199. Team Health

Track:

• cognitive load;
• on-call load;
• dependency wait;
• and roadmap interruption.

200. Coordination Metrics

• cross-team dependencies per epic;
• blocked time;
• coordinated releases;
• and incident handoffs.

201. Context Split

Consider splitting when:

• model has conflicting meanings;
• change cadence diverges;
• team cognitive load too high;
• or scaling/security differs materially.

202. Context Merge

Consider merging when:

• chatty synchronous calls;
• shared transaction invariants;
• no independent language;
• and separate operation adds little value.

203. Premature Split

Too many services before domain understanding.

204. Late Split

Monolith context has entrenched shared model.

205. Strangler Pattern

Incrementally extract context behind stable facade/event.

206. Branch by Abstraction

Introduce abstraction then redirect behavior.

207. Data Migration

Move ownership gradually with dual-read/dual-write controls.

208. Dual Write Risk

Requires reconciliation and clear cutover authority.

209. Shadow Read

Compare new context result without becoming authoritative.

210. Shadow Write

High-risk; can be used for migration with idempotency and reconciliation.

211. Ownership Transfer

When context moves teams, transfer:

• model knowledge;
• runbooks;
• contracts;
• incidents;
• and roadmap.

212. Team Boundary Evolution

Organization may evolve independently from domain boundary.

Keep authority explicit during transition.

213. Context Map Evolution

Version and review context map.

214. Architecture Decision Record

Use ADRs for boundary decisions.

215. ADR Contents

• context;
• decision;
• alternatives;
• consequences;
• migration;
• and owner.

216. Domain Event Storming

Can discover:

• commands;
• events;
• policies;
• actors;
• aggregates;
• and hotspots.

217. Big-Picture Event Storming

Maps end-to-end value stream.

218. Process-Level Event Storming

Focuses on one flow.

219. Design-Level Event Storming

Refines aggregate and command boundaries.

220. Domain Storytelling

Captures actors, work objects, and activities.

221. Context Discovery Workshop

Bring:

• domain experts;
• engineers;
• operations;
• product;
• security;
• and data owners.

222. Language Conflict Workshop

List overloaded terms and define context-specific meanings.

223. Invariant Workshop

Identify what must be atomic.

224. Authority Workshop

For each fact ask:

Who is allowed to say this is true?

225. Ownership Workshop

For each context ask:

Which team can change, deploy, operate, and support this independently?

226. Dependency Review

Challenge every synchronous context call.

227. Context Map Template

## Context Name

## Purpose

## Ubiquitous Language

## Owned Aggregates

## Owned Rules / Data

## Upstream Contexts

## Downstream Contexts

## Relationship Pattern

## APIs / Events / Files

## Consistency Expectations

## Security / Compliance

## Team Owner / On-Call

## SLIs / Runbooks

## Evolution Risks

228. Aggregate Template

## Aggregate Root

## Entities / Value Objects

## Commands

## Invariants

## Transaction Boundary

## External References / Snapshots

## Domain Events

## Concurrency Strategy

## Partitioning / Scale

## Recovery / Audit

229. Context Relationship Template

Upstream:
Downstream:
Relationship:
Published language:
Contract owner:
Versioning:
Consistency:
Failure behavior:
Migration:

230. Ownership Template

Context:
Accountable team:
Product owner:
Technical owner:
Data owner:
Contract owner:
On-call:
Security contact:
Critical consumers:
Repositories/services/topics:

231. Authority Matrix Template

232. Aggregate Invariants

Representative:

• Quote revision changes atomically;
• Acceptance references exact finalized revision;
• Product Order action/item relationship remains valid;
• Product Inventory change uses expected version;
• Agreement amendment preserves prior versions;
• and Fallout closure retains resolution evidence.

233. Context Invariants

Representative:

• only Pricing calculates authoritative offered price;
• only Quote accepts Offer;
• only Inventory changes installed Product state;
• only Billing creates invoiceable charge;
• only Agreement changes contractual commitment;
• and only Product Order owns requested Product action.

234. Worked Example: Product Word Conflict

Catalog Product = definition.

Quote Product = configured candidate.

Inventory Product = installed instance.

Solution:

• separate context models;
• explicit translation;
• stable references;
• no shared entity class.

235. Worked Example: Pricing and Quote

Pricing returns immutable Price Snapshot.

Quote owns reference/copy and lifecycle.

Quote does not recalculate.

Pricing does not transition Quote.

236. Worked Example: Approval Separation

Approval Context owns policy/decision.

Quote stores approval evidence/projection.

Presentation guard verifies evidence without owning workflow.

237. Worked Example: Large Quote Aggregate

10,000 items cause contention.

Design:

• Quote header aggregate;
• item partitions;
• revision manifest;
• finalization barrier;
• and semantic conflict handling.

238. Worked Example: Product Inventory

One Product per aggregate.

MODIFY Order references expected version.

Inventory rejects stale mutation.

239. Worked Example: Billing Handoff

Billing Handoff context translates accepted Charge into Billing contract.

Billing remains authority for active charge/invoice.

240. Worked Example: Shared Database

Quote and Order services write same item table.

Failure:

• dual authority;
• hidden coupling;
• impossible independent migration.

Target:

• separate ownership;
• event/API translation;
• staged data extraction.

241. Worked Example: Workflow Ownership

Workflow engine stores process state.

Product Order owns Order state.

Workflow commands Product Order; it does not directly update Order tables.

242. Worked Example: Platform Boundary

Platform provides outbox, idempotency, tracing, deployment, and security libraries.

Domain teams own price, Quote, Order, and Inventory semantics.

243. Worked Example: Team Cognitive Load

One team owns Catalog, Pricing, Quote, Order, Inventory, and Billing adapters.

Symptoms:

• long lead time;
• shallow expertise;
• incident overload.

Action:

• split by cohesive context and value stream;
• create platform support;
• preserve clear integration contracts.

244. Worked Example: Context Split

Extract Approval from Quote:

1. define approval contract;
2. publish immutable evidence;
3. shadow decisions;
4. migrate workflow;
5. switch Quote guards;
6. remove shared writes.

245. Worked Example: Context Merge

Two services call each other synchronously for every field update and share one transaction invariant.

They may be one context split prematurely.

246. Worked Example: Ownership Transfer

A team change occurs.

Transfer checklist includes:

• service catalog;
• on-call;
• data repair;
• schema registry;
• consumer list;
• ADRs;
• and active incidents.

247. Senior Engineer Operating Model

Start from semantic authority

Not service count.

Keep models context-specific

Translate at boundaries.

Define aggregates by invariants

Not object navigation.

Prefer one aggregate transaction

Coordinate cross-aggregate work explicitly.

Make ownership operational

Model, data, contract, runtime, and on-call.

Reduce coordination tax

Use stable published languages and async boundaries.

Protect domains from platform overreach

Platforms provide primitives, not business decisions.

Measure boundary health

Coupling, incidents, consumer breaks, and cognitive load.

Evolve incrementally

Strangler, shadowing, reconciliation, and explicit cutover.

248. Internal Verification Checklist

Context map

• Apa bounded contexts utama?
• Which terms have different meanings per context?
• Which contexts are core, supporting, or generic?
• Are upstream/downstream relationships documented?

Aggregates

• Apa aggregate utama pada Quote dan Order?
• Which invariants require immediate consistency?
• Are large aggregates partitioned deliberately?
• Are cross-aggregate processes explicit?

Authority

• Siapa authoritative untuk catalog, price, Quote, approval, Agreement, Order, Inventory, Billing, and tax facts?
• Are snapshots versus live references intentional?
• Is state ownership singular?
• Are shared database writes eliminated?

Contracts

• What APIs/events/files form published languages?
• Who owns versioning and deprecation?
• Are integration events separate from internal domain events?
• Is a consumer registry maintained?

Teams

• Siapa owner masing-masing context?
• Do owners cover code, data, contracts, runtime, and incidents?
• Is cognitive load sustainable?
• Are platform and domain-team responsibilities clear?

Operations

• Are service/data/topic ownership metadata complete?
• Can on-call identify authoritative context quickly?
• Are context-level SLIs and runbooks available?
• Are orphan services/contracts detected?

Evolution

• Which context should split or merge?
• How are dual-write and migration reconciled?
• Are ADRs/context maps versioned?
• What organizational changes threaten domain ownership?

249. Practical Exercises

Exercise 1 — Context discovery

Map 15 candidate contexts and their ubiquitous language.

Exercise 2 — Context map

Choose relationship type for every upstream/downstream pair.

Exercise 3 — Aggregate design

Define atomic invariants for Quote, Product Order, Product, and Agreement.

Exercise 4 — Authority matrix

Assign one authority to 50 important facts.

Exercise 5 — Team topology

Align stream-aligned, platform, enabling, and complicated-subsystem teams.

Exercise 6 — Migration

Plan extraction of one shared-table context without losing data.

250. Part Completion Checklist

You are done if you can:

• distinguish domain, subdomain, context, service, and aggregate;
• create a context map;
• define context-specific ubiquitous language;
• assign semantic and data authority;
• design aggregate boundaries from invariants;
• choose snapshot versus reference;
• separate domain and integration events;
• align context with accountable team ownership;
• detect shared-write and coordination smells;
• evolve boundaries incrementally;
• and create an internal context/ownership verification backlog.

251. Key Takeaways

1. Bounded context is semantic boundary, not service boundary.
2. The same word can represent different models across contexts.
3. Aggregate is immediate consistency boundary.
4. One state or fact should have one authority.
5. Cross-context translation protects local models.
6. Team ownership includes code, data, contract, runtime, and incidents.
7. Shared domain libraries and shared writes create hidden coupling.
8. Platform teams provide capabilities, not domain semantics.
9. Context maps and ownership metadata must evolve.
10. Internal CSG context and team topology must be verified.

252. References

Conceptual baseline:

• Domain-Driven Design strategic and tactical patterns.
• Bounded contexts, context maps, aggregates, domain events, repositories, policies, and anti-corruption layers.
• Team Topologies concepts: stream-aligned, platform, enabling, and complicated-subsystem teams.
• Conway’s Law, inverse Conway maneuver, modular monolith, microservice, strangler, and evolutionary architecture patterns.
• Enterprise CPQ, Quote, Product Order, Inventory, Billing, and Agreement domain boundaries.

These references do not define internal CSG bounded contexts, organization structure, or ownership assignments.