مستودع واحد مع Kotlin: تنظيم الكود وأفضل الممارسات

مقدمة إلى المستودع الأحادي مع Kotlin

غالبًا ما يواجه تطوير التطبيقات المعقدة الحديثة مشكلة إدارة الكود. يعد الاختيار بين المستودع الأحادي والمستودع المتعدد أحد القرارات المعمارية الرئيسية. في هذه المقالة، سنشرح كيفية تنظيم مستودع أحادي مع Kotlin باستخدام أفضل الممارسات والأدوات الحديثة.

المستودع الأحادي (monorepo) هو نهج يتم فيه تخزين جميع المشاريع والمكتبات والخدمات في مستودع واحد. بالنسبة لمطوري Kotlin، هذا مهم بشكل خاص بفضل نظام البناء القوي Gradle وإمكانية استخدام الكود المشترك بين الوحدات المختلفة.

مزايا المستودع الأحادي لمشاريع Kotlin

قبل الانتقال إلى التنظيم، دعنا نستعرض المزايا الرئيسية للمستودع الأحادي لـ Kotlin:

• إصدار واحد للتبعيات — تستخدم جميع الوحدات إصدارًا واحدًا من Kotlin والمكتبات والإضافات، مما يلغي تعارضات الإصدارات.
• إعادة هيكلة مبسطة — يتم التحقق من التغييرات في المكتبة المشتركة تلقائيًا بواسطة جميع الوحدات التابعة.
• تكوين مركزي — يتم تكوين إعدادات Gradle المشتركة وأدوات الفحص و CI/CD مرة واحدة.
• تسليمات ذرية — يمكن إجراء التغييرات المرتبطة في وحدات مختلفة في تسليمة واحدة.
• إعادة استخدام الكود — الأدوات المساعدة المشتركة و DTO ومنطق الأعمال متاحة بسهولة لجميع المشاريع.

هيكل المستودع الأحادي مع Kotlin و Gradle

دعنا نستعرض هيكل الدلائل الأمثل لمستودع أحادي لـ Kotlin باستخدام Gradle Multi-Module:

my-monorepo/├── build.gradle.kts          # ملف البناء الجذري├── settings.gradle.kts       # إعدادات الوحدات├── gradle.properties         # الخصائص المشتركة├── gradle/│   └── libs.versions.toml    # Version Catalog├── modules/│   ├── common/               # الأدوات المساعدة والنماذج المشتركة│   ├── domain/               # منطق الأعمال│   ├── data/                 # طبقة البيانات (API، قاعدة بيانات)│   ├── service-a/            # الخدمة المصغرة A│   ├── service-b/            # الخدمة المصغرة B│   └── shared-test/          # أدوات الاختبار المشتركة├── apps/│   ├── backend/              # التطبيق الرئيسي│   └── cli-tool/             # أداة سطر الأوامر└── config/    ├── checkstyle/           # تكوين أدوات الفحص    └── docker/               # Dockerfile للخدمات

إعداد settings.gradle.kts

يحدد ملف settings.gradle.kts جميع وحدات المشروع:

rootProject.name = "my-monorepo"

// تضمين جميع الوحداتinclude(    ":modules:common",    ":modules:domain",    ":modules:data",    ":modules:service-a",    ":modules:service-b",    ":apps:backend",    ":apps:cli-tool")

// إضافة لإدارة الإصداراتpluginManagement {    repositories {        gradlePluginPortal()        mavenCentral()    }}

استخدام Version Catalog (libs.versions.toml)

لإدارة التبعيات بشكل مركزي، نستخدم gradle/libs.versions.toml:

[versions]kotlin = "1.9.22"coroutines = "1.7.3"ktor = "2.3.7"exposed = "0.44.1"

[libraries]kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" }kotlinx-coroutines-core = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }ktor-server-core = { module = "io.ktor:ktor-server-core", version.ref = "ktor" }exposed-core = { module = "org.jetbrains.exposed:exposed-core", version.ref = "exposed" }

[plugins]kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }kotlin-serialization = { id = "org.jetbrains.kotlin.plugin.serialization", version.ref = "kotlin" }

مثال على build.gradle.kts لوحدة common

plugins {    alias(libs.plugins.kotlin.jvm)}

depend