(jp) =
<!–
–>
前の章では、ドメインの 3 つの主要な構成要素である DTO、アクション、およびモデルについて説明しました。 今日は、低レベルの技術的なことから一息ついて、哲学的な側面に焦点を当てます。ドメインの使用を開始する方法、ドメインを特定する方法、長期的に管理する方法などです。
# チームワーク
このシリーズの冒頭で、私が書いたすべてのパラダイムと原則は、開発者のチームが平均よりも大きな Laravel アプリケーションを何年にもわたって保守可能に保つのを助けるという目的に役立つと主張しました。
一部の人々は懸念を表明しました。新しいディレクトリ構造と複雑な原則の使用により、新しい開発者がすぐに参加することが難しくなるのではないでしょうか?
デフォルトの Laravel プロジェクトと、それらが初心者にどのように教えられるかを熟知している開発者であれば、これらのプロジェクトがどのように処理されるかを学ぶのに時間を費やす必要があることは事実です。 ただし、これは一部の人が考えるほど大したことではありません。
約 100 のモデル、300 のアクション、約 500 のルートを含むプロジェクトを想像してみてください。 これは私が考えているプロジェクトの規模です。 これらのプロジェクトの主な困難は、コードが技術的にどのように構造化されているかではなく、把握しなければならない膨大な量のビジネス知識に関するものです。 新しい開発者が、このプロジェクトが解決しているすべての問題を瞬時に理解できるとは期待できません。 コードを理解するには時間がかかりますが、もっと重要なのはビジネスです。 マジックや間接的な表現が少なければ少ないほど、混乱の余地は少なくなります。
このシリーズで展開しているアーキテクチャの目標を理解することは重要です。これは、文字数を最小限に抑えることでも、コードのエレガンスについてでもありません。 大規模なコードベースをナビゲートしやすくし、混乱の余地をできるだけ少なくし、プロジェクトを長期間健全に保つことです。
私たちは実際にこのプロセスを実際に経験しています。プロジェクトの 1 つで 3 人の開発者のチームと協力した後、同僚の Ruben が新しいバックエンド開発者として参加しました。
以前に Laravel の経験があったとしても、アーキテクチャは彼にとって初めてでした。 そこで、時間をかけて彼を案内しました。 数時間のブリーフィングとペアプログラミングの後、彼はすでにこのプロジェクトで独立して作業することができました. プロジェクトの範囲を完全に理解するのに間違いなく数週間かかりましたが、幸いなことに、アーキテクチャは彼の邪魔になりませんでした。逆に、Ruben は代わりにビジネス ロジックに集中することができました。
ブログ シリーズのこの時点まで作成した場合は、このアーキテクチャがすべてのプロジェクトの特効薬になることを意図したものではないことを理解していただければ幸いです。 単純なアプローチの方がうまくいく場合もあれば、より複雑なアプローチが必要な場合もあります。
# ドメインの識別
基本的なドメイン構成要素についての知識が得られたので、実際のコードを正確にどのように書き始めるかという疑問が生じます。 構築しようとしているものをよりよく理解するために使用できる方法論はたくさんありますが、重要な点が 2 つあります。
- あなたは開発者ですが、ビジネス上の問題を理解し、それをコードに変換することが主な目標です。 コード自体は目的を達成するための手段にすぎません。 解決しようとしている問題に常に集中してください。
- お客様と向き合う時間を確保してください。 実用的なプログラムを作成するために必要な知識を抽出するには時間がかかります。
「コードを書くプログラマー」ではなく、「現実世界の問題と技術的解決策の間の翻訳者」として自分の仕事を考えるようになりました。 長期にわたるプロジェクトに取り組む場合、この考え方が重要であると固く信じています。 コードを書くだけでなく、解決しようとしている現実の問題を理解する必要があります。
チームの規模によっては、顔を合わせてやり取りする必要がない場合があります。 全て ただし、すべての開発者は、コードで解決しようとしている問題を理解する必要があります。
これらのチームのダイナミクスは非常に複雑なトピックであるため、独自の本を書く価値があります。 実際、このトピックに特化した文献はたくさんあります。 ここから先は、これらの問題をどのようにドメインに変換するかについて話すことができるので、今のところはこのままにしておきます。
第 1 章で、このアーキテクチャの目標の 1 つは、技術的な特性ではなく、現実世界での意味に基づいてコードをグループ化することだと書きました。 クライアントとオープンなコミュニケーションをとっている場合、彼らのビジネスが何であるかを理解するには、かなりの時間がかかることに気付くでしょう。 多くの場合、クライアントは自分自身でそれを正確に認識していない可能性があります.座って初めて、クライアントはそれについて徹底的に考え始めます.
そのため、時間の経過とともに変化するドメイン グループを恐れる必要はありません。 あなたはで始めるかもしれません Invoice しかし、半年後、あなたとあなたのチームが完全に把握するには大きすぎることに気付きました。 請求書の作成と支払いは、それ自体が 2 つの複雑なシステムであるため、後で 2 つのドメイン グループに分割できます。
私の見解では、ドメイン構造を反復し、リファクタリングし続けることは健全であるということです。 適切なツールがあれば、ドメインの変更、分割、リファクタリングはまったく難しくありません。 あなたのIDEはあなたの友達です！ 私の同僚である Freek は、デフォルトの Laravel アプリケーションをこのシリーズで説明したアーキテクチャにリファクタリングする実用的な例を時間をかけて記録しました。 彼のライブ リファクタリング セッションを以下で見ることができます。
要約すると、後でいつでもリファクタリングできるため、ドメインの使用を開始することを恐れないでください。
したがって、このドメイン指向アーキテクチャの使用を開始する場合は、これが私が採用するアプローチです。プロジェクト内のサブシステムを特定し、サブシステムが時間の経過とともに変化する可能性があることを認識してください。 クライアントと一緒に座って、何かを書き留めるように依頼したり、イベント ストーミング セッションを行ったりすることもできます。 プロジェクトがどうあるべきかのイメージを一緒に形成します。
また、私たちのドメイン コードには依存関係がほとんどないため、非常に柔軟性があり、コードを移動したり、コードをリファクタリングしたりするのにあまりコストがかかりません。
ここまでこのシリーズを楽しんでいますか？ ご質問やフィードバックはありますか？ お気軽に ツイッター または電子メール。
来週はコードに戻り、最終的にアプリケーション層に到達します。楽しみにしています!
//platform.twitter.com/widgets.js