Topic
Domain Modeling
Business concepts, ownership, events, and boundaries that make the domain visible in code.
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.