バウンデッドコンテキストワーキンググループ

属性

概要

現在、コードは Ruby 名前空間を使用して名前空間化されていますが、コードの整理方法に明確なルールやガイドラインがありません。新しい名前空間が常に作成されており、バウンデッドコンテキストをより適切に表現するために新しい概念を既存の名前空間内にネストできる場合が多いにもかかわらず、その必要がないケースがよくあります。一貫して名前空間化されたコードは、モジュール化されたコードベースの前提条件です。

このワーキンググループでは：

• GitLab Rails コードベースを構成するバウンデッドコンテキストを特定する
• 明確な理由なく新しいトップレベル名前空間が増殖するのを止める
• エンジニアリング組織に整合した豊かなドメインロジックを持つモジュールを持つ

コンテキスト

GitLab Rails モノリスをモジュール型モノリスに分割する提案は、現在の GitLab コードベースの段階でモジュール化がなぜ重要なのかを詳しく説明しています。モジュール型モノリスに向けて進捗を達成するために、まず GitLab Rails モノリスに現在存在するモジュールとバウンデッドコンテキストが何かを理解する必要があります。

活動

ワーキンググループのメンバーは：

• 自分のバウンデッドコンテキストに関連するファイルを分類する。
• 同期ミーティングに参加し、質問を持ち寄り、進捗を報告する。
• バウンデッドコンテキストを特定するプロセスとガイドラインについてフィードバックを提供する。
• それぞれのステージ/ドメインのモジュール化エバンジェリストとして行動する。
• バウンデッドコンテキストの最終リストが包括的であることを確認するレビューを支援する。

コミュニケーション

• ワーキンググループは最初は週次でミーティングを行い、APAC と AMER に適したタイムゾーンを交互に使用します。その後、隔週に変更できます。
• #wg_bounded_contexts Slack チャンネルが作成され、質問や非同期でのコミュニケーションができます。
• 最初のミーティング後は、作業が非同期で進められることが期待されます。各チームメンバーは自分自身のファイルリストを分類する作業を進めることができます。
• スプレッドシート（または代替手段）で作業することで、分類されたファイルの進捗と残作業を簡単に追跡できます。
• ミーティングのファシリテートと週次ステータス更新の報告の DRI は @fabiopitino とコントリビュートを希望する他のメンバーが担当します。
• 最終的な Issue やフォローアップのアイデアは ~modular_monolith ラベルを使用して作成されます。

終了基準

以下の条件を満たしたときにワーキンググループを解散できます：

詳細

ワーキンググループは、Ruby コードベース、特に app/ と lib/ フォルダのドメインコードをマッピングし、バウンデッドコンテキストのリストを作成します。六角形アーキテクチャのドメインレイヤー（コア）を主な対象としたいため、最初は app/controllers と app/views を除外する場合があります。

コードベースのマッピングプロセスでは以下を実施します：

• スプレッドシートに Ruby ファイルをすべてリストし、定義されたガイドラインに従ってコンポーネントに分類します。同じディレクトリ下のファイルは一般的にまとめて分類できるため、これは多くの時間を要しません。
• lib ディレクトリ内では、gem として抽出すべき汎用コードと、app のコードと同じ名前空間を持つべきドメインコードを区別します。同じドメインに関連するすべてのコードは全く同じ名前空間を持つべきです。例えば、Ci::（app から）と Gitlab::Ci::（lib から）を並存させるべきではありません。
  • gem として抽出すべきコードと app と lib のクロスカッティングな懸念（汎用基底クラス、ユーティリティ、ロガー、フレームワークコードなど）のために特別な platform カテゴリを設けます。
• ネストされたクラスのリネームに気を取られることなく、トップレベルのバウンデッドコンテキストにのみ焦点を当てることが重要です。これはこの機能を所有するチームの裁量によるリファクタリング活動ですが、ワーキンググループのスコープではありません。
• 類似した名前空間とマージ戦略を特定します。以下のいずれかです：
  • より大きなドメインを表す新しい名前空間を作成し、クラスをそこに移動する。
  • バウンデッドコンテキストの代表的な名前空間を特定し、他のすべてのクラスをそこに移動する。
• 2 つの名前空間が似ているように見えても完全に異なるコンテキストで動作する場合、それぞれのバウンデッドコンテキスト下に移動することで曖昧な名前空間を区別します。
• 複数の責任を持ち、分割すべき名前空間を特定します。この場合、クラスはそのドメインをより適切に表現する他の名前空間に移動する可能性があります。
• 可能な限り既存のトップレベル名前空間を再利用するようにします。
• その他のすべてを無視します（非 Ruby コード、設定、スペック、コントローラー、ビュー、Rake タスク、Grape API、GraphQL）。

バウンデッドコンテキストのリストは完璧である必要はありません。GitLab Rails コードベースで機能するドメインの十分な表現であり、各クラスが存在できる名前空間が 1 つだけで曖昧さがないことが重要です。このリストを継続的に改善し、バウンデッドコンテキストの作成、削除、リネームのプロセスを整備する必要があります。

ロールと責任

ワーキンググループは、GitLab のさまざまなステージの代表者で構成される必要があります。各代表者は、特定の GitLab DevOps ステージにおけるバックエンドの専門家として自分のドメインを代表するファンクショナルリードの役割を担います。

参加者は理想的にはモジュール化とドメイン駆動設計に関連する成果の推進に興味があることが望まれます。ワーキンググループの設立については #development、#backend、#engineering-fyi Slack チャンネルでコミュニケーションします。参加者がいないステージについては、そのステージで働くエンジニアリングリーダーにサポートを求めます。

ページのソースコードを見る - ページの編集 - please contribute.