[CHORE] Apply Google Recommended Architecture (KMP Structure)

[dmp100]

Task Description

Kotlin Multiplatform(KMP) 프로젝트에 Google 권장 아키텍처를 기반으로 data, domain, presentation 레이어를 명확히 분리하고, 구조적 확장성을 확보한다.

Apply the Google-recommended architecture to the Kotlin Multiplatform (KMP) project. Separate the layers into data, domain, and presentation to ensure clear structure and maintainability.

Todo List

• Create base package structure: data, domain, presentation

• Define Repository interface in domain

• Implement RepositoryImpl in data (dummy logic for now)

• Define UseCase class structure for business logic

• Create base ViewModel in presentation

• Verify dependency direction (presentation → domain → data)

• Document architecture with architecture-layers.puml

Development Scope

Common/Shared Logic

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• [FEAT] Implement Shared Design System (Theme & Components) Task Description #11
• [FEAT] Implement Fake Data for Web UI Prototype #9

👤 Suggested Assignees

• dmp100

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Approach

Implement Google's recommended clean architecture in the Kotlin Multiplatform (KMP) shared module by creating data, domain, and presentation layers with clear separation of concerns and proper dependency flow (presentation → domain → data).

Observations

The project is a Kotlin Multiplatform application with a shared module containing source sets for Android, iOS, JVM, JS, and common code. The shared module currently has only platform detection utilities, with no architectural layers implemented. The version catalog includes coroutines (v1.10.2) and lifecycle/ViewModel libraries (v2.9.5), but these dependencies are not yet declared in the shared module. The composeApp and server modules are minimal, making this a clean slate for establishing architectural patterns.

Assumptions

Assumption 1: Choice of example domain entity for demonstration

Options Considered:

• Create a generic "Item" or "Example" entity with no business meaning
• Create a "PatchNote" entity that aligns with the project's domain

Chosen Option: Use a PatchNote entity (id, title, content, version, timestamp) as the example domain model

Rationale: This provides a realistic example that developers can immediately understand and relate to the project's purpose, making the architectural patterns more intuitive to follow and extend.

Assumption 2: Platform-specific implementation strategy

Options Considered:

• Use expect/actual declarations from the start for repository implementations
• Keep everything in commonMain with dummy data, defer platform-specific implementations

Chosen Option: Implement the repository entirely in commonMain with in-memory dummy data

Rationale: This keeps the initial architecture simple and focused on demonstrating layer separation. Platform-specific implementations (network clients, database drivers) can be added later using expect/actual when real data sources are integrated, following the established pattern.

Assumption 3: Dependency injection approach

Options Considered:

• Add a DI framework (Koin) immediately
• Use manual constructor injection and defer DI framework integration

Chosen Option: Use manual constructor injection with simple factory functions

Rationale: No DI framework (Koin, Kodein, Dagger) is currently configured in the project, and adding one would be premature for establishing base architecture patterns. Manual injection keeps the initial setup simple, demonstrates clear dependency flow, and allows DI framework integration later without architectural changes.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Project Setup and Structure

Establish the foundational package structure and add required dependencies to the shared module.

Task 1: Add Architecture Dependencies

Add the necessary multiplatform libraries to support the architecture layers.

• Update shared/build.gradle.kts to declare kotlinx-coroutines-core and androidx-lifecycle-viewmodel-compose in the commonMain.dependencies block
• These dependencies are already defined in gradle/libs.versions.toml and just need to be referenced
• Coroutines will support async operations in use cases and repositories
• Lifecycle ViewModel will provide the presentation layer foundation

Task 2: Create Layer Package Structure

Create the three-layer package structure in the shared module's commonMain source set.

• Create directory structure in shared/src/commonMain/kotlin/org/patchnote/patchnote/: data/, domain/, presentation/
• Within domain/: create subdirectories model/, repository/, usecase/
• Within data/: create subdirectory repository/
• Within presentation/: create subdirectory viewmodel/
• This structure follows clean architecture conventions with clear layer boundaries

🤖 Prompt for AI agents

Set up the foundational clean architecture structure and dependencies for the
shared KMP module.

Update shared/build.gradle.kts:
- Add kotlinx-coroutines-core to commonMain dependencies
- Add androidx-lifecycle-viewmodel-compose to commonMain dependencies

Create package structure in
shared/src/commonMain/kotlin/org/patchnote/patchnote/:
- Create data/repository/ directories
- Create domain/model/, domain/repository/, domain/usecase/ directories
- Create presentation/viewmodel/ directories

Phase 2: Domain Layer Implementation

Define the core business logic layer with entities, repository contracts, and use cases.

Task 1: Create Domain Model

Define the example domain entity that demonstrates the architecture pattern.

• Create PatchNote.kt in shared/src/commonMain/kotlin/org/patchnote/patchnote/domain/model/
• Define PatchNote as a data class with fields: id (String), title (String), content (String), version (String), createdAt (Long timestamp)
• This entity represents pure business data with no framework dependencies
• Keep it immutable to follow functional programming best practices

Task 2: Define Repository Interface

Create the repository contract that defines data access operations.

• Create PatchNoteRepository.kt in shared/src/commonMain/kotlin/org/patchnote/patchnote/domain/repository/
• Define PatchNoteRepository as an interface with suspend functions: getAllPatchNotes(): List, getPatchNoteById(id: String): PatchNote?
• Use suspend functions to support async operations
• Return domain models (PatchNote), not data layer DTOs
• The interface defines what operations are needed without specifying how they're implemented

Task 3: Create Use Case

Implement the business logic component that orchestrates domain operations.

• Create GetPatchNotesUseCase.kt in shared/src/commonMain/kotlin/org/patchnote/patchnote/domain/usecase/
• Define GetPatchNotesUseCase as a class that accepts PatchNoteRepository via constructor
• Implement an invoke() suspend function (operator function) that calls repository.getAllPatchNotes() and returns Result<List>
• Wrap the operation in try-catch to return Result.success() or Result.failure()
• Use cases should contain business logic and coordinate between repositories; for this example, it's a simple pass-through to demonstrate the pattern

🤖 Prompt for AI agents

Implement the domain layer with the core business logic, entities, and
contracts.

Create PatchNote.kt in domain/model/:
- Define immutable data class PatchNote with fields: id (String), title
(String), content (String), version (String), createdAt (Long)

Create PatchNoteRepository.kt in domain/repository/:
- Define interface with suspend functions: getAllPatchNotes(): List<PatchNote>
and getPatchNoteById(id: String): PatchNote?

Create GetPatchNotesUseCase.kt in domain/usecase/:
- Create class accepting PatchNoteRepository via constructor
- Implement suspend operator invoke() function that returns
Result<List<PatchNote>>
- Call repository.getAllPatchNotes() wrapped in try-catch
- Return Result.success() or Result.failure()

Phase 3: Data Layer Implementation

Implement the data access layer with the repository implementation.

Implement Repository with Dummy Data

Create the concrete repository implementation that provides dummy data.

• Create PatchNoteRepositoryImpl.kt in shared/src/commonMain/kotlin/org/patchnote/patchnote/data/repository/
• Implement PatchNoteRepository interface
• Create a private mutableListOf with 3-5 sample patch notes as dummy data
• Implement getAllPatchNotes() to return the dummy list with a small delay (delay(500)) to simulate network latency
• Implement getPatchNoteById() to find and return a note by id, or null if not found
• Use kotlinx.coroutines.delay to demonstrate async behavior
• Add comments indicating this is dummy implementation and should be replaced with real data sources (API client, database) later

🤖 Prompt for AI agents

Implement the data layer with a concrete repository using dummy in-memory data.

Create PatchNoteRepositoryImpl.kt in data/repository/:
- Implement PatchNoteRepository interface
- Create private mutableListOf<PatchNote> with 3-5 sample patch notes
- Implement getAllPatchNotes() with delay(500) to simulate network, return the
dummy list
- Implement getPatchNoteById() to find by id or return null
- Add comments noting this is dummy implementation to be replaced with real data
sources

Phase 4: Presentation Layer Implementation

Create the presentation layer component that manages UI state and exposes data to the UI.

Create Base ViewModel

Implement the ViewModel that connects the domain layer to the UI.

• Create PatchNoteViewModel.kt in shared/src/commonMain/kotlin/org/patchnote/patchnote/presentation/viewmodel/
• Extend ViewModel from androidx.lifecycle.ViewModel
• Accept GetPatchNotesUseCase via constructor
• Create a private MutableStateFlow<List> and expose it as public StateFlow (immutable)
• Implement a loadPatchNotes() function that launches a coroutine (viewModelScope.launch), calls the use case, and updates the StateFlow with results
• Handle both success and failure cases from the use case Result
• This ViewModel demonstrates the pattern of exposing state via StateFlow and coordinating domain operations
• Add init block that calls loadPatchNotes() on creation

🤖 Prompt for AI agents

Implement the presentation layer with a ViewModel that manages UI state.

Create PatchNoteViewModel.kt in presentation/viewmodel/:
- Extend androidx.lifecycle.ViewModel
- Accept GetPatchNotesUseCase via constructor
- Create private MutableStateFlow<List<PatchNote>> and expose as public
StateFlow
- Implement loadPatchNotes() function using viewModelScope.launch
- Call use case and update StateFlow, handle both success and failure cases from
Result
- Add init block that calls loadPatchNotes()

Phase 5: Documentation and Verification

Document the architecture and verify dependency direction compliance.

Task 1: Create Architecture Diagram

Create a PlantUML diagram documenting the layer structure and dependencies.

• Create architecture-layers.puml in the project root directory
• Use PlantUML package notation to show three layers stacked vertically: Presentation (top), Domain (middle), Data (bottom)
• Show key components in each layer: PatchNoteViewModel (presentation), GetPatchNotesUseCase + PatchNoteRepository interface + PatchNote entity (domain), PatchNoteRepositoryImpl (data)
• Use arrows to show dependency direction: Presentation depends on Domain, Domain defines contracts, Data implements contracts
• Add color coding: blue for presentation, green for domain, gray for data
• Include notes explaining: presentation layer calls use cases, use cases coordinate business logic using repository interfaces, data layer implements repository interfaces
• Add stereotype labels <>, <>, <>, <> to clarify component roles
• Use solid arrows for direct dependencies, dashed arrows to show implementation relationships

Task 2: Verify Dependency Direction

Ensure the implementation follows clean architecture dependency rules.

• Review import statements in each layer to confirm: presentation imports only from domain, domain has no imports from data or presentation, data imports from domain (interfaces only)
• Verify that domain layer contains no concrete implementations from data layer
• Verify that PatchNoteRepositoryImpl implements the interface from domain, not the other way around
• Document the dependency flow in a README section or architecture documentation
• Confirm that the ViewModel receives the use case via constructor (dependency injection pattern), and the use case receives the repository via constructor

🤖 Prompt for AI agents

Create documentation and verify the clean architecture implementation follows
proper dependency rules.

Create architecture-layers.puml in project root:
- Use PlantUML package notation showing three vertical layers: Presentation
(blue), Domain (green), Data (gray)
- Show components: PatchNoteViewModel, GetPatchNotesUseCase, PatchNoteRepository
interface, PatchNote entity, PatchNoteRepositoryImpl
- Add arrows showing dependency flow: Presentation → Domain, Data → Domain
- Include stereotypes <<ViewModel>>, <<UseCase>>, <<Repository>>, <<Entity>>
- Add notes explaining layer responsibilities and dependency rules
- Use solid arrows for dependencies, dashed for implementations

Verify dependency direction:
- Check imports: presentation only imports domain, domain imports nothing from
data/presentation, data imports domain interfaces only
- Confirm domain has no concrete data layer implementations
- Verify constructor injection pattern throughout

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Set up the foundational clean architecture structure and dependencies for the
shared KMP module.

Update shared/build.gradle.kts:
- Add kotlinx-coroutines-core to commonMain dependencies
- Add androidx-lifecycle-viewmodel-compose to commonMain dependencies

Create package structure in
shared/src/commonMain/kotlin/org/patchnote/patchnote/:
- Create data/repository/ directories
- Create domain/model/, domain/repository/, domain/usecase/ directories
- Create presentation/viewmodel/ directories
===============================================================================

Task: 2

Implement the domain layer with the core business logic, entities, and
contracts.

Create PatchNote.kt in domain/model/:
- Define immutable data class PatchNote with fields: id (String), title
(String), content (String), version (String), createdAt (Long)

Create PatchNoteRepository.kt in domain/repository/:
- Define interface with suspend functions: getAllPatchNotes(): List<PatchNote>
and getPatchNoteById(id: String): PatchNote?

Create GetPatchNotesUseCase.kt in domain/usecase/:
- Create class accepting PatchNoteRepository via constructor
- Implement suspend operator invoke() function that returns
Result<List<PatchNote>>
- Call repository.getAllPatchNotes() wrapped in try-catch
- Return Result.success() or Result.failure()
===============================================================================

Task: 3

Implement the data layer with a concrete repository using dummy in-memory data.

Create PatchNoteRepositoryImpl.kt in data/repository/:
- Implement PatchNoteRepository interface
- Create private mutableListOf<PatchNote> with 3-5 sample patch notes
- Implement getAllPatchNotes() with delay(500) to simulate network, return the
dummy list
- Implement getPatchNoteById() to find by id or return null
- Add comments noting this is dummy implementation to be replaced with real data
sources
===============================================================================

Task: 4

Implement the presentation layer with a ViewModel that manages UI state.

Create PatchNoteViewModel.kt in presentation/viewmodel/:
- Extend androidx.lifecycle.ViewModel
- Accept GetPatchNotesUseCase via constructor
- Create private MutableStateFlow<List<PatchNote>> and expose as public
StateFlow
- Implement loadPatchNotes() function using viewModelScope.launch
- Call use case and update StateFlow, handle both success and failure cases from
Result
- Add init block that calls loadPatchNotes()
===============================================================================

Task: 5

Create documentation and verify the clean architecture implementation follows
proper dependency rules.

Create architecture-layers.puml in project root:
- Use PlantUML package notation showing three vertical layers: Presentation
(blue), Domain (green), Data (gray)
- Show components: PatchNoteViewModel, GetPatchNotesUseCase, PatchNoteRepository
interface, PatchNote entity, PatchNoteRepositoryImpl
- Add arrows showing dependency flow: Presentation → Domain, Data → Domain
- Include stereotypes <<ViewModel>>, <<UseCase>>, <<Repository>>, <<Entity>>
- Add notes explaining layer responsibilities and dependency rules
- Use solid arrows for dependencies, dashed for implementations

Verify dependency direction:
- Check imports: presentation only imports domain, domain imports nothing from
data/presentation, data imports domain interfaces only
- Confirm domain has no concrete data layer implementations
- Verify constructor injection pattern throughout

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!