ドメインの理解とチームの構築: 変化の基礎 (II)

複雑なプロジェクトに着手するには、包括的なコンテキストの収集と同時に、ドメイン専門家の洞察を活用して、新しい視点からドメインの知識にアプローチする必要があります。このアプローチにより、技術チームがビジネス目標に合わせて調整され、製品ライフサイクル全体を通じて情報に基づいた意思決定を行うための基本的なロードマップが確立されます。

前のチームと現在のアプリケーション ユーザーとの最初の知識収集セッションは非生産的であることが判明しました。 私たちは、固有のリスクにもかかわらず、独立して進めることを一時的に検討しました。

EventStorming: ドメインの公開

私は技術リーダーとして、プロジェクトの複雑さとチームの所有権の必要性を考慮して、最初からドメイン主導のアプローチを支持しました。これによりドメインが中心となり、コミュニケーションを合理化し、アプリケーションの現在の状態のマッピングを容易にする共通の理解 (ユビキタス言語) が促進されました。

Miro テンプレートを使用して EventStorming セッションを開始し、効果的に焦点を当てるための構造と凡例を提供しました。 セッション前の準備または最初の説明を通じて、EventStorming の概念を事前に理解しておくと、非常に有益です。

私たちの構造化された EventStorming プロセスは次のとおりでした:

1. ドメイン イベントの調査 (全体像): ドメインの専門家と主要なシステム イベントを特定し、時系列に並べて検証し、ギャップや依存関係を強調します。
2. 改良と分析: 説明メモの追加、質問の文書化、各イベントの詳細な分析、重要な決定点の特定。
3. ドメイン モデリング: 集約と境界の特定、アクターと役割の定義、トリガー コマンドの確立、ポリシーとビジネス ルールの文書化、内部/外部イベント トリガーの特定。
4. 文書化と検証: 収集した情報の整理と整理、明確な関係の確立、利害関係者とのモデルの検証、参照ドキュメントの作成。

EventStorming は、ドメインを理解するだけでなく、ドメイン駆動設計 (DDD) 原則を戦略的および戦術的に適用するための基盤も提供しました。

戦略的なドメイン駆動設計

重要な最初のステップには、ドメインを戦略的に構築することが含まれていました。 システムの複雑さと技術/ビジネスの調整の必要性により、DDD 原則が採用されました。 コンテキスト マッピング は、リファクタリングを待っているモノリス内であっても、非常に貴重であることがわかりました。 私たちは、共有カーネルを使用して単一の技術的コンテキスト内で動作する境界コンテキストを特定しました。 この分析は深くは調査されていませんが、プロジェクトをドメイン指向のアーキテクチャに導き、技術開発とチーム間のコラボレーションの両方を改善しました。

境界の定義 (境界付けられたコンテキスト)

境界付けられたコンテキスト を特定することで、システム間および外部システムの関係が明確になり、複雑さが簡素化され、将来のモジュール化の基盤が確立されました。 これらの最初の決定は、定義されたコンテキストに沿った管理可能なコンポーネントへのモノリスの分解を導きます。 これにより、簡素化、切り離し、または削除する領域の優先順位付けと特定も容易になりました。 私たちは、外部システムとの対話のための 破損防止レイヤー (ACL) を実装し、システムの整合性を維持することに重点を置きました。

5 つの主要なコンテキストが特定されました:

• 注文の割り当て
• ラベルの生成
• 注文の準備
• 電子商取引の統合
• 大量注文の準備

これらの決定により、持続可能なアーキテクチャが促進され、ビジネス ニーズに合わせた開発が実現しました。

ユビキタス言語

堅牢なユビキタス言語を確立することが重要であることが判明しました。 ドメインの専門家と開発者のコ​​ラボレーションによって作成された共有言語の利点は、翻訳の労力や誤解をはるかに上回ります。 この生きたリソースにより、技術チームとドメインの専門家がつながり、コミュニケーションが改善され、誤解が減り、コード内でのドメインの正確な表現が保証されました。 これにより、効率的でビジネスに合わせた技術ソリューションが促進されました。

戦術的ドメイン駆動設計

戦略的フレームワークに従って、戦術的な DDD 原則を実装してコードを構造化し、ドメインの現実を反映し、長期的な持続可能性を確保しました。

エンティティと値オブジェクト

エンティティと値オブジェクトの区別を理解することが重要です。

エンティティ

エンティティは、属性が変更された場合でも、一意で永続的なアイデンティティを保持します。 例:

• 注文
• 製品
• 運送業者
• ショップ
• 顧客

値オブジェクト

価値オブジェクトには個々のアイデンティティがありません。それらの値がそれらを定義します。 同一の属性は等価性を意味します。 これらは不変であり、ドメイン全体に現れる概念をカプセル化するのに最適です。例:

• 製品リファレンス
• ProductEan13
• 注文参照
• 価格
• 体重
• 配送番号

このアプローチにより、責任が明確に定義された、より理解しやすくモジュール化されたコードが作成されました。

値オブジェクトの例:

<?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(string $value)
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}

サービス

サービスは目的と実装パターンによって分類されています。

ドメイン サービス

ドメイン サービスは、エンティティや値に適合しないビジネス ロジックをカプセル化し、インフラストラクチャに依存せずにドメイン ルール内で厳密に動作します。

<?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(string $value)
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}

アプリケーションサービス

アプリケーション サービスは、ドメイン操作と外部インタラクションを調整し、複雑な操作を一元化し、ドメインとインフラストラクチャを分離します。 これらには、ユースケース、コマンド ハンドラー、イベント ハンドラーが含まれます。

インフラストラクチャ サービス

インフラストラクチャ サービスは、外部コンポーネント (データベース、ファイル システムなど) の対話を処理し、ドメインに依存しないアダプターとして機能します。

<?php
class CheapestCarrierGetter
{
    public function get(
        DeliveryOptionCarrierCollection $deliveryOptionCarriers,
        Weight $orderWeight,
        Country $country,
        PostalCode $postalCode,
        bool $isCashOnDelivery = false,
    ): Carrier {
        // Logic to get the cheapest carrier
    }
}

サービス分類

サービスは、機能および関連する設計パターン (トランスフォーマー、ビルダー、ファクトリー、プレゼンター、ノーティファイアー、バリデーター、クライアント) によって分類されます。

この最初のドメイン モデリングは不完全で反復的ではありましたが、チームの参加とコミットメントを促進しました。 さらなる洗練と再構築が期待されていました。

推奨される DDD リソース:

• 「ドメイン駆動設計: ソフトウェアの中心部の複雑さへの取り組み」Eric Evans 著
• 「ドメイン駆動設計の実装」Vaughn Vernon 著
• 「PHP のドメイン駆動設計」Carlos Buenosvinos、Christian Soronellas、Keyvan Akbary 著

チームの構築: タックマンのステージ

DDD の採用は、タックマンの段階 (フォーミング、ストーミング、ノーミング、パフォーミング) に続くチーム編成と並行して行われました。

形成

初期チームメンバーはプロジェクトをレビューし、運用を文書化し、技術的および組織的基盤 (プロセス、標準、ツール) を確立しました。

嵐

些細な意見の相違が、働き方、コミュニケーション方法、意思決定プロセスの定義につながりました。

ノーミング

チーム合意、コーディング標準、開発プロセス、WIP 制限、展開ルール、技術的負債管理、および ADR が確立されました。

パフォーマンス

確立されたフレームワークにより、効率的な製品開発、価値ある取り組みの優先順位付け、継続的な改善の文化の育成が可能になりました。

ドキュメント: 糖尿病モデル

ドキュメントは、GitLab Pages と Jekyll を使用し、Diátaxis モデル (チュートリアル、ガイド、説明、リファレンス) に従って、Just the Docs テーマで管理されました。 イベント カタログと AsyncAPI を使用したドキュメントの自動化が計画されましたが、完全には実装されていませんでした。

以上がドメインの理解とチームの構築: 変化の基礎 (II)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。