モジュールの命名規則
前回の内容はこちら
前回学習した「把握」、「整理」、「組み立て」の３プロセスを繰り返して作成したアーキテクチャー設計図ですが慣れるまでは何がなんのアプリかわからなくなってしまいます。そのため命名規則に従うことが大切なのです。
命名規則を導入するべき理由
モジュールに命名規則を導入する理由としては下記の3つが主に挙げられます。
- 各モジュールの性質を明確にできる
→命名規則に従うことでモジュールの性質とモジュール内の要素の性質を明確にできる - 参照アーキテクチャを確実に適用できる
→参照アーキテクチャを確実に適用するとともに扱っているモジュールを一貫した方法で管理できる - 既知のパターンを正規化できる
→作成したアーキテクチャの設計パターンが増えるにつれパターンが正規化されコミュニケーション全般が向上する
各レイヤーの命名規則
モジュールのレイヤーごとに命名規則を記載して行きます。
基盤レイヤーモジュール
- Module_Lib
- 汎用ライブラリ
- Module_IS(IntegrationService)
- 外部サービスを利用・正規化するための技術的なラッパー、連携サービス（IntegrationBuilderで作成する）
- Module_Drv
- 特定の連携サービスに使用する。ドライバモジュールを作成すると特殊な実装を複数含む同一のAPIを公開できる。複数のプリンターに対応するドライバが良い例で同じ処理をする異なるシステムに接続する部品（IntegrationBuilderで作成する）
- Module_Th
- アプリのテーマおよび全体的なルックアンドフィールの要素を含む
- Module_Pat
- ユーザーインターフェイスの再利用可能なパターンやブロックに適用する。基盤レイヤーなのでビジネスロジックを入れてはいけません。（基本的にHTMLのみを入れるCSSはThに入れるようにする）
- Module_Plug
- 再利用可能なモバイルプラグインに対応する
- Module_MTh,Module_MPat…
- モバイル専用の場合はMをつけてあげる
コアレイヤーモジュール
- Module_CS
- 再利用可能なコアサービス（ビジネス専用のパブリックエンティティやパブリックアクションを入れる）
- Module_BL
- ビジネスロジックをカプセル化するためのモジュールで公開するアクションを入れる
- Module_CW
- 再利用可能なブロックなどのコアウィジェットを入れる。様々なパターンやブロックをライフサイクルに応じて幾つかのモジュールに分割することも可能
- Module_Eng
- 複雑なビジネスルールにおける計算処理などを入れるエンジンモジュール
- Module_Sync
- データ同期用のモジュール
- Module_API
- 外部コンシューマにAPIを公開する技術的なラッパー
- Module_MCS,Module_MBL,Module_MCW…
- モバイル用にはMをつける
エンドユーザーレイヤーモジュール
エンドユーザーレイヤーのモジュール名は最終的にURLの一部になるためユーザーにとってわかりやすい端的で簡潔な命名をする必要があります
その他
前述の命名規則に則って命名作業を行う際はエンドユーザーレイヤーから行いましょう。
なお、上記で説明してきた命名規則はあくまで推奨なので厳密にこれらを守らなければいけないというわけではないのでそういった趣旨の問題には注意してください。組織ごとに定義して使っても構わないものになります。
次回
今回は画像もないため淡々とした座学になってしまいました。そのためこのページの最後に幾つか問題を用意してみたので気になる方はそこまでみていっていただけると嬉しいです。（完全自作問題のため間違いがあったら教えていただけると嬉しいです）
次回はアプリケーションの構成を学んでいこうと思います。
一問一答
問題(全13問)
Q1. 命名規則を導入することで、各モジュールの何を明確にできるか？
- モジュールの性質
- モジュールの速度
- モジュールのコスト
- モジュールのサイズ
Q2. 命名規則を導入することで、参照アーキテクチャにどのような影響を与えるか？
- 参照アーキテクチャの適用を困難にする
- 参照アーキテクチャの適用を確実にする
- 参照アーキテクチャを不要にする
- 参照アーキテクチャの適用方法を変更する
Q3. 命名規則を導入することで、設計パターンが増えるとどのような効果があるか？
- 設計パターンの管理が困難になる
- 設計パターンがバラバラになる
- 設計パターンが正規化される
- 設計パターンの必要性が減る
Q4. 命名規則の導入によって、コミュニケーションに与える影響として適切なのは？
- コミュニケーションが混乱する
- コミュニケーションが向上する
- コミュニケーションの重要性が低下する
- コミュニケーションの手段が減る
Q5. Module_Lib の役割として正しいものはどれか？
- 外部サービスを利用・正規化する技術的なラッパー
- 汎用ライブラリを提供する
- ユーザーインターフェイスの再利用可能なパターンを含む
- データ同期を行う
Q6. Module_IS の主な目的は何か？
- 外部サービスを利用・正規化するための技術的なラッパー
- 再利用可能なコアサービスを提供する
- モバイル専用のプラグインを作成する
- テーマやルックアンドフィールを管理する
Q7. Module_Drv の適切な用途は次のうちどれか？
- 特定の連携サービスのためにドライバを提供し、同じAPIで異なるシステムと接続できるようにする
- アプリ全体のテーマやスタイルを管理する
- コアビジネスロジックをカプセル化し、公開アクションを提供する
- ユーザーインターフェイスの再利用可能なパターンのみを管理する
Q8. Module_Th の役割として正しいものはどれか？
- ユーザーインターフェイスの再利用可能なパターンを提供する
- アプリ全体のテーマやルックアンドフィールを管理する
- 外部コンシューマ向けにAPIを公開する
- データ同期を担当する
Q9. Module_CS の適切な用途はどれか？
- 再利用可能なコアサービスを提供する
- ユーザーインターフェイスのパターンを適用する
- 外部APIとの統合を行う
- テーマやスタイル情報を格納する
Q10. Module_BL はどのような役割を持つか？
- ビジネスロジックをカプセル化し、公開アクションを含む
- データの同期を担当する
- 外部サービスとの統合を行う
- 再利用可能なモバイルプラグインを管理する
Q11. Module_API の主な役割は何か？
- 外部コンシューマ向けにAPIを公開する技術的なラッパー
- ビジネスルールに関する計算処理を行うエンジンモジュール
- データ同期を管理する
- モバイル専用のUIパターンを提供する
Q12. Module_MTh や Module_MPat のように M を付ける理由は何か？
- モバイル専用のモジュールであることを示すため
- モジュールのバージョン管理を行うため
- モジュールの重要度を示すため
- デスクトップ向けのモジュールと区別するため
Q13. エンドユーザーレイヤーのモジュール命名に関して、適切なルールはどれか？
- 技術的な用語を含めるべき
- ユーザーにとってわかりやすく、端的で簡潔な命名をする
- すべてのモジュール名に Module_ を付ける必要がある
- ビジネスロジックを含む名前を付ける
解答
Q1,1
Q2,2
Q3,3
Q4,2
Q5,2
Q6,1
Q7,1
Q8,2
Q9,1
Q10,1
Q11,1
Q12,1
Q13,2
コメント