• 2018-05-26
ウズマスター戦記
ウズマスター戦記 https://www.uzumax.org/2018/05/django_27.html

Djangoのデザインパターン考察~パッケージ構成~

前回でひとまず「アプリケーション」を作って起動確認したわけですが、「アプリケーションって何なの?」という所も踏まえて考えてみました。


アプリケーションという用語

以下のコマンドで作成されるフォルダ一個をDjangoでは一アプリケーションと言います。


>python manage.py startapp start_samples

これね、「アプリケーション」って言ってしまうと日本語では変に聞こえると思いますね。
「この製品全体のことだろ!!」って思いますもん。
Androidアプリの場合は、アプリ=全体ですからね。

紛らわしいので、アプリケーションではなく機能と表現すると良いと思います。


  • プロジェクト全体:システム、サービス、プロジェクト
  • startappで作られるもの:機能
  • URL一発に相当するもの:処理


と表現すると、認識齟齬が無くなると思います。

一機能の単位

Djangoは一機能の中に複数のアクションを投入するものです。

from django.http import HttpResponse

def index(request):
    return HttpResponse("日本一平凡なDjango")

def list(request):
    return HttpResponse("日本一平凡な一覧表示")

def new(request):
    return HttpResponse("日本一平凡な新規作成")

def edit(request):
    return HttpResponse("日本一平凡な編集")


#続く


だからシステム全体を一つのviews.pyに突っ込むことも可能なわけですが、そんな馬鹿な設計はありません。

かと言って一処理事に一機能を作るのも冗長です。

だから「一機能の中にどれくらいの量の処理を突っ込むか?」というデザインパターンを考える必要があります。

これは定石がありまして、基本的に以下の規模が一機能です。


  • 一覧表示
  • 新規登録
  • 更新
  • 削除


つまり、マスタメンテナンス画面における一つのテーブルに対するCRUDで一機能が基本です。

テーブル毎に一機能を作るのが基本です。

まあ、実際の開発の現場では「この処理はテーブルを三つ使うからテーブル毎に一機能とはならない」とかありますが、
その場合はどこか主となるテーブルの機能に突っ込むか、別機能として分けるか、そこはケースバイケース。プロジェクト個別の判断となります。

よくプロジェクトの機能一覧には「大分類」「中分類」「小分類」と分類があることがありますが、Djangoにおける一機能は小分類に相当すると考えると良いでしょう。


機能を沢山作っていくと

一機能を作った直後である現在、プロジェクトのパッケージは以下のようになっています。

heibon_django/
    heibon_django/  ←ルートパッケージ
    start_samples/  ←機能


「heibon_django」はプロジェクト全体を代表する特別なパッケージで、それ以外が任意で作るパッケージです。
この調子でどんどん機能を追加していきましょう。


heibon_django/
    departments/  ←機能
    enployees/  ←機能
    heibon_django/  ←ルートパッケージ
    start_samples/  ←機能
    start1_samples/  ←機能
    start2_samples/  ←機能
    start3_samples/  ←機能
    start4_samples/  ←機能


というように親フォルダ直下に機能フォルダが無限に増えてしまいます。
ルートパッケージとそれ以外の機能フォルダは立場が違うし。

汚いっしょ、これ。。。

このままではプロジェクトが進むほどに汚くなっていきます。
ここで考え方は二つあります。

気にすんな作戦

一つは単純。このまま続行。気にすんな作戦です。

まず基本的思想として「一プロジェクトの中に百機能も二百機能も作るな!!」というものがあります。

だから親フォルダ直下に機能フォルダが多数ならんで、それで問題が生じるくらいに機能が増えてきたら、それはサービスのデザインが間違っていて、別のプロジェクトに分割するべき、というものです。

機能が増える程にDjangoも重くなってしまいますからね、程々の単位で別プロジェクトに分けていった方が開発は効率的でしょう。

この考え方をマイクロクラスタ構成と言います。


階層分け作戦

百も二百も機能があるわけではないにしろ、やっぱり親フォルダ直下のフォルダがゾロゾロ増えていくのは気になるという人も多いと思います。

そんな時は階層分けが可能です。


heibon_django/
    apps  ←機能パッケージ
       departments/  ←中分類
       employees/  ←中分類
       samples/  ←中分類
       start_samples/  ←中分類
          start1_samples/   ←小分類
          start2_samples/ ←小分類
          start3_samples/ ←小分類
          start4_samples/ ←小分類
   heibon_django/  ←ルートパッケージ


「あ、な~んだ」という感じでしょう。
自分でフォルダを作ってそこに入れるのは自由です。
好きに作っちゃって下さい。

これでパッケージ構成はスッキリします。

しかし、このやり方にも欠点がありまして、パスを通すのが大変になるんですよ。

from apps.samples.start_samples import views

「10文字かそこら増えるだけじゃん?」と思うかもしれませんが、実際にコーディングしていると段々ストレスが溜まってきます。

う~ん。

結論

パッケージ構成に正解は無いです。

理想を言えば、プロジェクトのサイズを出来るだけ小さくした上で、親フォルダ直下にそのまま機能を並べていくというデザインが一番でしょう。

しかし現実として、必ずしも開発に都合の良いサービスデザインにはなりませんので、最初から覚悟を決めて階層化しておいた方が手堅いとも言える。

結局、パッケージ構成が綺麗かどうかのは、パッケージ構成を考える今ではなくて、それ以前のサービスデザインの段階でもう命運が決まっているんですよ。

システム開発はままなりません。

これは永遠の悩みですね。

バックナンバー

0 件のコメント:

コメントを投稿

お気軽にコメント下さい。