Topic
API Design
Clear contracts, authorization boundaries, validation, and pragmatic HTTP API decisions.
Hide Preview Content at the Server Boundary, Not in CSS
Do not ship gated text and merely blur it in the client; transform previews at the server response boundary while preserving an honest layout cue.
Server-Driven API Responses for Mobile App Compatibility
Keep changing display policy and experiments server-side for old app versions, but isolate that translation at the API boundary to protect the domain model.
Keep Guest Data Masking in the Presentation Layer
Learn why guest masking and author flags belong at the presentation boundary, keeping domain logic clean while preventing raw data exposure.
Translate Exceptions at Module Boundaries
Keep implementation exceptions inside their modules and define explicit translation boundaries that prevent dependencies from leaking upward.
Swagger vs REST Docs: Choose API Documentation by Context
Compare Swagger and REST Docs by test enforcement, code intrusion, customization, and a pragmatic migration path for legacy APIs.
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.