حالات الاستخدام وحدود النطاق

Business rules scattered across screens drift and duplicate. Giving each rule its own use case creates one trusted place for important logic to live.

A use case captures one app action, like place an order or refresh the feed. It reads as a verb and does exactly that one meaningful thing.

A tidy use case exposes a single entry point. Many teams use Kotlin invoke so the object is called like a function at the call site.

A use case receives repository interfaces, never concrete clients. It orchestrates them but stays unaware of Ktor, SQL or any platform detail.

Because it has no UI and no I/O of its own, a use case is pure logic you can test in commonTest with simple fakes and zero device setup.

The domain boundary is the line use cases guard. Nothing technical, no JSON or HTTP types, crosses it; only clean models and clear results pass through.

If a use case imports a Ktor or SQLDelight type, the boundary has leaked. Keep those framework imports in the data layer where they belong.

Bigger flows combine smaller ones. A checkout use case might call validate cart, then place order, each independently tested and reused elsewhere.

A use case usually returns a domain model or a sealed Result, so callers handle success and failure without catching framework exceptions.

Shared ViewModels call use cases in response to user intents. The ViewModel coordinates; the use case decides. Each keeps a single, clear duty.

For a trivial passthrough, a use case can feel like ceremony. Add one when logic is real or shared; do not wrap a one-line call just for symmetry. 🙂

What belongs inside a well-designed use case?

You learned use cases hold one action each, depend on interfaces, and guard the domain boundary so frameworks and UI stay firmly outside. 🎉