mcpField
D
django

django

github.com/imankulov開発451 回インストール3 週間前に更新
リポジトリ

django について

django は、Django プロジェクト向けの開発スキルで、Celery タスクの構成やアプリ間シグナルなどの規約をまとめています。コンポーネント別の資料と検証項目も案内します。

主な機能

  1. 01サービス関数を中心とした Celery タスク構成
  2. 02エントリーポイントからのタスク登録
  3. 03カスタムシグナルによるアプリ間連携
  4. 04Django コンポーネント別資料の参照
  5. 05マイグレーションと管理画面の確認

活用シーン

  1. 01Django の非同期タスクコードの構成
  2. 02Django アプリ間イベントの連携
  3. 03マイグレーションと管理画面の変更確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/imankulov/skills --skill django

インストール後、Claude Code で/djangoを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
admin.md
migrations.md
models.md
service-provider.md
views.md

詳細

Django 開発パターン

Django プロジェクトで推奨する規約です。アプリのアーキテクチャとモジュールの構成については、python スキルを参照してください。これらのパターンはすべての Python プロジェクトに適用できます。

Celery タスクのパターン

タスク関数の末尾には _task を付け、サフィックスのないサービス関数を呼び出します。 これにより、インポートをすっきり保てます。エイリアスを付けずに from myapp.services import execute_report と記述できます。

from myapp.services import execute_report, fail_report

@celery_app.task(bind=True)
def execute_report_task(self, report_id: int) -> None:
    """Execute report generation asynchronously."""
    try:
        execute_report(report_id)
    except Exception as exc:
        if self.request.retries >= self.max_retries:
            fail_report(report_id=report_id, error_message=str(exc))
        raise

タスクのスケジュール設定は、サービス関数からではなく、エントリーポイント（api.py、admin.py）で行います。これにより、循環インポートを防ぎ、呼び出し元でタスクのスケジュール設定が明確になります。すべてのエントリーポイントで再利用できるよう、ビジネスロジックはサービス関数に置きます。タスクはサービスを呼び出すだけにします。

スケジュール用ヘルパー

複数のエントリーポイントで、保留中のレコードを作成してタスクをスケジュールする必要がある場合は、tasks.py に schedule_* 関数を切り出します。これは「tasks.py にロジックを置かない」というルールの唯一の例外です。この関数の責務は、レコードの作成とタスクのスケジュール設定を組み合わせることだけです。

# tasks.py
def schedule_refresh_all(user: User) -> RefreshOperation:
    """Create the pending record and schedule the task."""
    operation = create_pending_refresh_operation(user)
    refresh_all_task.delay(operation.id)
    return operation

エントリーポイントでは、create-then-delay のパターンを重複して実装する代わりに、schedule_refresh_all() を呼び出します。

アプリ間のシグナル

あるアプリが別のアプリのイベントに反応する必要がある場合は、直接インポートしたり、モデルシグナル（post_save など）を使ったりせず、カスタム Django シグナルを使います。

  • シグナルを送信するアプリの signals.py でシグナルを定義します。
  • Model.save() ではなく、サービス関数からシグナルを送信します。これにより、シグナルを送信するタイミングと、シグナルが持つデータを制御できます。
  • 受信側アプリの signals.py でレシーバーを定義し、AppConfig.ready() を通じて登録します。
# emitting app: accounts/signals.py
from django.dispatch import Signal
websites_updated = Signal()

# emitting app: accounts/services.py
websites_updated.send(sender=refresh_all, user=user, added=added)

# listening app: filtering/signals.py
from django.dispatch import receiver
from accounts.signals import websites_updated

@receiver(websites_updated)
def on_websites_updated(sender, user, added, **kwargs):
    ...

# listening app: filtering/apps.py
class FilteringConfig(AppConfig):
    def ready(self) -> None:
        import_module("filtering.signals")

依存関係は一方向に保ちます。受信側アプリは送信側アプリをインポートしますが、その逆は行いません。

コンポーネント別リファレンス

特定の Django コンポーネントに関する詳しいパターンは、必要に応じて以下のリファレンスを読み込んでください。

検証

Django コードを書いた後は、リファレンスに記載されている、見落としやすいルールを確認してください。

  • 管理画面のアクションでは、変更処理にサービス関数を呼び出す
  • admin.py のテストは書かない — テストする価値のあるロジックは、まず services.py に移す
  • 永続化されたフィールドを置き換える場合は、既存の値を保持するデータマイグレーションを含める。データの損失がユーザーに見える場合は、マイグレーションのテストも追加する

コメント

Markdown 対応