모듈 내부의 패키지 구성

A package groups related Kotlin files under a dotted name. Good packages make a growing shared module easy to navigate. 📁

Every file starts with a package line. It should mirror the folder path so the structure stays predictable for everyone.

Prefer grouping by feature over grouping by type. A cart package keeps its model, logic, and helpers together in one place.

A clean split is domain for pure models and rules, and data for networking and storage. The boundary keeps each part focused.

Start packages with a reverse-domain name like com.acme.shared. It keeps your code from clashing with library packages.

Keep the folder tree matching the package names. When they line up, anyone can find a class just from its full name.

Put the types you expose in one obvious public package, like com.acme.shared.api. Callers then have a single place to look.

Keep helpers in an internal package such as .impl or .util. The name signals at a glance that callers should stay out.

Avoid endless nesting. A shallow tree of a few clear packages is easier to scan than ten layers of tiny folders.

Use the same package layout in commonMain, androidMain, and iosMain. Matching paths make expect and actual pairs easy to spot.

Read your package list top to bottom. The names alone should explain what the module does and where each concern lives.

Group by feature or layer, mirror folders to packages, keep it shallow, and hide internals. A clear tree scales as the module grows. 🎉