Topic
Domain Modeling
Business concepts, ownership, events, and boundaries that make the domain visible in code.
Model Drafts by Meaning: Status or Separate Storage?
Choose a status for ordinary lifecycle stages and separate versioned storage for distinct preparatory data, based on domain meaning and compatibility cost.
Design Data Relationships for Organizational Reality
Prefer simple relationship cardinality, then account for observed requirement churn, decision habits, and deadline constraints instead of predicting every future change.
Avoid the Admin Common Module That Owns Every Domain
Keep admin features from reversing domain dependencies. Preserve service boundaries and accept small duplication while admin requirements continue to diverge.
Discover Domain Concepts from Information and Behavior
Use information and process or behavior from case-dependent viewpoints to distinguish transport events from domain concepts.
Why Domain Concepts Should Not Mirror Database Tables
Model business importance, hierarchy, and behavior instead of creating one domain object and repository for every persistence table.
Prove Domain Knowledge Through Real Problem Solving
Domain expertise grows through real operations, policy, and cross-team problems. Show it through concrete problem solving, not terminology alone.
Find Domain Boundaries Through Concept Lifecycles
Compare creation, reads, changes, and deletion to judge cohesion, coupling, and boundaries among products, orders, payments, shipping, and settlement.
Protect Order Snapshots with Soft Delete and Boundaries
Separate current products from immutable order snapshots, preserve refund history, and use status transitions or archives before destructive deletion.
Keep Core Entities Light by Delaying ORM Associations
Decide ORM associations by lifecycle and responsibility, separating searchable supporting data so core entities stay focused and adaptable.
Enums or Code Tables? Let the Rate of Change Decide
Use enums for stable values and focused tables for frequently changing ones without turning one common-code table into a dumping ground.
One Database, Separate Boundaries: Controlling Data Access by Domain
How separate entity and repository boundaries can protect core rules from integration code even when both areas share one database table.
What a Utility Bill Can Teach Us About Domain Modeling
How a utility bill revealed a missing delinquency concept in a repayment model and why everyday artifacts can guide software design.
Rank Your Domain Concepts Before You Spend Design Effort
Identify a small first tier of domain concepts, separate supporting flows, and spend limited design time on the service's center.
Before Fixing Circular Dependencies, Fix the Domain Model
Resolve confusing ownership and concept boundaries before using interfaces or dependency inversion to treat an apparent circular reference.
Turn Production Incidents into Shared Domain Knowledge
Use incident reviews, working notes, concept maps, and rotated operations to reduce domain knowledge gaps across a software team.
Measure Before Replacing Outbox Polling
Evaluate outbox polling with realistic load tests, then consider a simpler application-level delivery path before adopting log tailing.
Publish Events Where the Business Flow Is Visible
Place event publication in the layer that understands the completed business action, while keeping implementation-specific cases explicit.
Why a My Page Is Not a Domain
A My Page is a client-facing view, not a business domain. Keep orders, products, and coupons with their real owners and combine them at the boundary.
Give Cross-Domain Behavior to the Domain That Owns It
Before placing a caller-owned interface across modules, identify which domain owns the action and let callers depend on that capability.
Where Cross-Domain Coordination Code Belongs
Use business ownership, cohesion, imports, and a package-move experiment to place code that coordinates a primary action with another domain's rule.
Domain Models First: A Conservative Approach to JPA Associations
A cautious way to map JPA entities: start with IDs, add associations only when lifecycles truly align, and model business concepts independently.
Do Not Split Modules Before the Domain Has Matured
Domain maturity comes from understanding policy, behavior, and operating reality. Let those lessons reveal module boundaries instead of freezing guesses too early.