Topic
API Design
Clear contracts, authorization boundaries, validation, and pragmatic HTTP API decisions.
Compose My Page Data Without Inventing a My Domain
Build My page summaries through a dedicated composition layer while keeping user, order, and product responsibilities in their proper domains.
Authorization Without Redundant Reads
Resolve the logged-in user once, keep access checks focused, and separate system-wide administration from channel-level permissions.
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.
One Read Model for Guests and Members
Return public reaction counts and member-specific state through one read flow while keeping optional identity distinct from required authentication.
Designing Domain Models Beyond the Shape of the UI
A tree-shaped API does not require a tree-shaped domain. Keep the client contract at the presentation boundary and compose it from internal concepts.
Put Logic Where Change Is Cheapest: Client vs. Server
Place display-only work near the UI, but centralize meaningful or changing values when multiple clients and shipped app versions make updates expensive.
Build APIs for Clarity, Not REST Purity
Use REST ideas where they improve an HTTP contract, but let client clarity, team consistency, domain boundaries, and change cost decide the API.
Validate at the Boundary, Simplify the Core
Turn API input into complete business values at the presentation boundary, keep nulls out of inner flows, and validate stored data when it enters the system.
Keep API Request Models Out of the Core Domain
Convert external request objects into business-owned values at the presentation boundary so the API depends inward and the core never depends back.
Provider Identity and Authentication Boundaries for Platform APIs
How a small platform API resolves provider keys into a domain identity, separates tenant data, and chooses an authentication boundary that fits its scale.
Do Not Create a DTO for Every Layer by Habit
Use DTOs where data crosses a boundary with a different contract. Mapping has a cost, but so does letting external request shapes define the inside of a service.