แพ็กเกจภายในเครื่องและโมดูลฟีเจอร์

เหตุใดจึงต้องมีโมดูลฟีเจอร์

// Without modules: one giant target recompiles everything
// With modules: changes to FeatureA only recompile FeatureA

การสร้างแพ็กเกจภายในเครื่อง

mkdir Features/UserProfile
cd Features/UserProfile
swift package init --name UserProfile --type library

การเพิ่มลงในโครงการ Xcode

// In Xcode:
// File → Add Package Dependencies → Add Local...
// Select the package directory

การอ้างอิงแพ็กเกจภายในเครื่อง

.package(path: "../Features/UserProfile"),
// In the target:
.product(name: "UserProfile", package: "UserProfile")

พื้นผิวส่วนติดต่อสาธารณะ

// UserProfile/Sources/UserProfile/ProfileView.swift
public struct ProfileView: View {
  public init() {}
  public var body: some View { Text("Profile") }
}

การนำไปใช้งานภายใน

// Only visible within UserProfile module:
final class ProfileCache { ... }
struct ProfileMapper { ... }

โครงสร้างโมดูลฟีเจอร์

// UserProfile/
// ├── Sources/UserProfile/
// │   ├── Domain/         (entities, use cases, protocols)
// │   ├── Data/           (repositories)
// │   └── Presentation/   (views, view models)
// └── Tests/UserProfileTests/

โมดูลแกนกลางที่ใช้ร่วมกัน

// CoreNetwork package
// CoreDesign package
// Both imported by FeatureA and FeatureB

กราฟการพึ่งพา

// GOOD:
// FeatureA → CoreNetwork
// FeatureB → CoreNetwork
// BAD:
// FeatureA → FeatureB  (tight coupling)

ประโยชน์ด้านเวลาการสร้าง

// Change in UserProfile → only UserProfile recompiles
// App target links the new binary → fast incremental build

การทดสอบโมดูลฟีเจอร์

// Run all tests:
swift test --package-path Features/UserProfile
// Or let Xcode run them as part of the main test plan

ตรวจสอบความเข้าใจอย่างรวดเร็ว

สรุปบทเรียน