複雑なプロジェクトに着手するには、包括的なコンテキストの収集と同時に、ドメイン専門家の洞察を活用して、新しい視点からドメインの知識にアプローチする必要があります。このアプローチにより、技術チームがビジネス目標に合わせて調整され、製品ライフサイクル全体を通じて情報に基づいた意思決定を行うための基本的なロードマップが確立されます。
前のチームと現在のアプリケーション ユーザーとの最初の知識収集セッションは非生産的であることが判明しました。 私たちは、固有のリスクにもかかわらず、独立して進めることを一時的に検討しました。
私は技術リーダーとして、プロジェクトの複雑さとチームの所有権の必要性を考慮して、最初からドメイン主導のアプローチを支持しました。これによりドメインが中心となり、コミュニケーションを合理化し、アプリケーションの現在の状態のマッピングを容易にする共通の理解 (ユビキタス言語) が促進されました。
Miro テンプレートを使用して EventStorming セッションを開始し、効果的に焦点を当てるための構造と凡例を提供しました。 セッション前の準備または最初の説明を通じて、EventStorming の概念を事前に理解しておくと、非常に有益です。
私たちの構造化された EventStorming プロセスは次のとおりでした:
EventStorming は、ドメインを理解するだけでなく、ドメイン駆動設計 (DDD) 原則を戦略的および戦術的に適用するための基盤も提供しました。
重要な最初のステップには、ドメインを戦略的に構築することが含まれていました。 システムの複雑さと技術/ビジネスの調整の必要性により、DDD 原則が採用されました。 コンテキスト マッピング は、リファクタリングを待っているモノリス内であっても、非常に貴重であることがわかりました。 私たちは、共有カーネルを使用して単一の技術的コンテキスト内で動作する境界コンテキストを特定しました。 この分析は深くは調査されていませんが、プロジェクトをドメイン指向のアーキテクチャに導き、技術開発とチーム間のコラボレーションの両方を改善しました。
境界付けられたコンテキスト を特定することで、システム間および外部システムの関係が明確になり、複雑さが簡素化され、将来のモジュール化の基盤が確立されました。 これらの最初の決定は、定義されたコンテキストに沿った管理可能なコンポーネントへのモノリスの分解を導きます。 これにより、簡素化、切り離し、または削除する領域の優先順位付けと特定も容易になりました。 私たちは、外部システムとの対話のための 破損防止レイヤー (ACL) を実装し、システムの整合性を維持することに重点を置きました。
5 つの主要なコンテキストが特定されました:
これらの決定により、持続可能なアーキテクチャが促進され、ビジネス ニーズに合わせた開発が実現しました。
堅牢なユビキタス言語を確立することが重要であることが判明しました。 ドメインの専門家と開発者のコラボレーションによって作成された共有言語の利点は、翻訳の労力や誤解をはるかに上回ります。 この生きたリソースにより、技術チームとドメインの専門家がつながり、コミュニケーションが改善され、誤解が減り、コード内でのドメインの正確な表現が保証されました。 これにより、効率的でビジネスに合わせた技術ソリューションが促進されました。
戦略的フレームワークに従って、戦術的な DDD 原則を実装してコードを構造化し、ドメインの現実を反映し、長期的な持続可能性を確保しました。
エンティティと値オブジェクトの区別を理解することが重要です。
エンティティは、属性が変更された場合でも、一意で永続的なアイデンティティを保持します。 例:
価値オブジェクトには個々のアイデンティティがありません。それらの値がそれらを定義します。 同一の属性は等価性を意味します。 これらは不変であり、ドメイン全体に現れる概念をカプセル化するのに最適です。例:
このアプローチにより、責任が明確に定義された、より理解しやすくモジュール化されたコードが作成されました。
値オブジェクトの例:
<code class="language-php"><?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;
}
}</code>サービスは目的と実装パターンによって分類されています。
ドメイン サービスは、エンティティや値に適合しないビジネス ロジックをカプセル化し、インフラストラクチャに依存せずにドメイン ルール内で厳密に動作します。
<code class="language-php"><?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;
}
}</code>アプリケーション サービスは、ドメイン操作と外部インタラクションを調整し、複雑な操作を一元化し、ドメインとインフラストラクチャを分離します。 これらには、ユースケース、コマンド ハンドラー、イベント ハンドラーが含まれます。
インフラストラクチャ サービスは、外部コンポーネント (データベース、ファイル システムなど) の対話を処理し、ドメインに依存しないアダプターとして機能します。
<code class="language-php"><?php
class CheapestCarrierGetter
{
public function get(
DeliveryOptionCarrierCollection $deliveryOptionCarriers,
Weight $orderWeight,
Country $country,
PostalCode $postalCode,
bool $isCashOnDelivery = false,
): Carrier {
// Logic to get the cheapest carrier
}
}</code>サービスは、機能および関連する設計パターン (トランスフォーマー、ビルダー、ファクトリー、プレゼンター、ノーティファイアー、バリデーター、クライアント) によって分類されます。
この最初のドメイン モデリングは不完全で反復的ではありましたが、チームの参加とコミットメントを促進しました。 さらなる洗練と再構築が期待されていました。
推奨される DDD リソース:
DDD の採用は、タックマンの段階 (フォーミング、ストーミング、ノーミング、パフォーミング) に続くチーム編成と並行して行われました。
初期チームメンバーはプロジェクトをレビューし、運用を文書化し、技術的および組織的基盤 (プロセス、標準、ツール) を確立しました。
些細な意見の相違が、働き方、コミュニケーション方法、意思決定プロセスの定義につながりました。
チーム合意、コーディング標準、開発プロセス、WIP 制限、展開ルール、技術的負債管理、および ADR が確立されました。
確立されたフレームワークにより、効率的な製品開発、価値ある取り組みの優先順位付け、継続的な改善の文化の育成が可能になりました。
ドキュメントは、GitLab Pages と Jekyll を使用し、Diátaxis モデル (チュートリアル、ガイド、説明、リファレンス) に従って、Just the Docs テーマで管理されました。 イベント カタログと AsyncAPI を使用したドキュメントの自動化が計画されましたが、完全には実装されていませんでした。
以上がドメインの理解とチームの構築: 変化の基礎 (II)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
