(jp) =
人間はカテゴリで考えます。私たちのコードはそれを反映したものでなければなりません。
まず第一に、私は「ドメイン」という用語を思いつきませんでした。これは、人気のあるプログラミング パラダイムである DDD、つまり「ドメイン駆動設計」から得たものです。 Oxford Dictionary によると、「ドメイン」は次のように記述できます。 「活動または知識の特定の範囲」.
私の使用する「ドメイン」という言葉は、DDD 内で使用される場合とまったく同じ意味ではありませんが、いくつかの類似点があります。 DDD に精通している場合は、この本全体を通してこれらの類似点に気付くでしょう。 関連する場合は、重複や相違点について言及するように最善を尽くしました。
だから、ドメイン。 それらを「グループ」、「モジュール」と呼ぶこともできます。 それらを「サービス」と呼ぶ人もいます。 どちらの名前を使用する場合でも、ドメインは、解決しようとしている一連のビジネス上の問題を表しています。
ちょっと待って… この本で初めて「エンタープライズ」という用語を使ったのに気がついた。「ビジネス上の問題」だ。 この本を読み進めていくと、私が理論的、経営陣、ビジネスの側面から離れるように最善を尽くしたことに気付くでしょう。 私自身が開発者であり、物事を実用的に保つことを好みます。 したがって、別のより単純な名前は「プロジェクト」です。
例を挙げましょう: ホテルの予約を管理するアプリケーションです。 顧客、予約、請求書、ホテルの在庫などを管理する必要があります。
最新の Web フレームワークは、関連する概念の 1 つのグループを取り上げ、それをコードベース全体の複数の場所に分割することを教えてくれます。 あなたは契約を結びます。
クライアントから「今すぐすべてのコントローラーで作業する」または「モデルのディレクトリでしばらく作業する」ように言われたことがありますか? いいえ — 請求、顧客管理、または予約機能に取り組むように求められます。
これらのグループは、私がドメインと呼んでいるものです。 それらは、プロジェクト内で一緒に属する概念をグループ化することを目的としています。 これは一見些細なことのように思えるかもしれませんが、想像以上に複雑です。 そのため、この本の一部では、コードの順序を適切に保つための一連のルールとプラクティスに焦点を当てています。
明らかに、私があなたに与えることができる数式はありません.ほとんどすべては、あなたが取り組んでいる特定のプロジェクトに依存します. ですから、この本が決まった一連のルールを与えているとは考えないでください。 むしろ、好きなように使用して構築できるアイデアのコレクションを提供するものと考えてください。
これは学習の機会であり、遭遇した問題に対処できる解決策ではありません。
# ドメインとアプリケーション
アイデアをグループ化すると、明らかに疑問が生じます。どこまで行くのか? たとえば、モデル、コントローラー、リソース、検証ルール、ジョブなど、請求書に関連するすべてのものをグループ化できます。
これにより、従来の HTTP アプリケーションで問題が発生します。多くの場合、コントローラーとモデルの間に 1 対 1 のマッピングがありません。 確かに、REST API や従来の CRUD コントローラーの大部分では、厳密な 1 対 1 のマッピングが存在する可能性がありますが、残念ながら、これらはルールの例外であり、苦労することになります。 たとえば、請求書は単に単独で処理されるわけではなく、顧客に送信する必要があり、請求するには予約が必要です。
そのため、ドメイン コードとそうでないものをさらに区別する必要があります。
一方では、すべてのビジネス ロジックを表すドメインがあります。 一方、そのドメインを使用 (消費) してフレームワークと統合し、エンドユーザーに公開するコードがあります。 アプリケーションは、エンドユーザーが使いやすい方法でドメインを使用および操作するためのインフラストラクチャを提供します。
＃ 実際には
では、これは実際にはどのように見えるのでしょうか? ドメインは、モデル、クエリ ビルダー、ドメイン イベント、検証ルールなどのクラスを保持します。 これらすべての概念を詳しく見ていきます。
アプリケーション層は、1 つまたは複数のアプリケーションを保持します。 すべてのアプリケーションは、すべてのドメインの使用が許可されている分離されたアプリと見なすことができます。 一般に、アプリケーションは互いに通信しません。
1 つの例は、標準の HTTP 管理パネルであり、別の例は REST API です。 また、Laravel の職人であるコンソールを、独自のアプリケーションと考えるのも好きです。
高レベルの概要として、ドメイン指向プロジェクトのフォルダー構造は次のようになります。
app/Domain/Invoices/
├── Actions
├── QueryBuilders
├── Collections
├── DataTransferObjects
├── Events
├── Exceptions
├── Listeners
├── Models
├── Rules
└── States
app/Domain/Customers/
アプリケーション層は次のようになります。
app/App/Admin/
├── Controllers
├── Middlewares
├── Requests
├── Resources
└── ViewModels
app/App/Api/
├── Controllers
├── Middlewares
├── Requests
└── Resources
app/App/Console/
└── Commands# 名前空間について
上記の例が Laravel の規則に従っていないことに気付いたかもしれません。 \App 単一のルート名前空間として。 アプリケーションはプロジェクトの一部にすぎず、複数存在する可能性があるため、使用しても意味がありません \App すべての根源として。
Laravel のデフォルト構造に近づきたい場合は、そうすることができます。 これは、次のような名前空間になることを意味します \App\Domain と \App\Api. でも、好きなことをするのは自由です。
ただし、ルート名前空間を分離したい場合は、 composer.json:
"autoload" :
"psr-4" :
"App\\" : "app/App/",
"Domain\\" : "app/Domain/",
"Support\\" : "app/Support/"
私も持っていることに注意してください \Support ルート名前空間は、今のところ、どこにも属さないすべての小さなヘルパーのゴミ捨て場と考えることができます。
どのようなフォルダー構造を使用する場合でも、最も重要なことは、同じ技術的特性を持つコードのグループではなく、関連するビジネス コンセプトのグループで考え始めることです。
ただし、各グループ、各ドメイン内には、個々のグループ内で簡単に使用できるようにコードを構造化する余地があります。 この本の最初の部分では、ドメインを内部で構造化する方法と、時間の経過とともにコードベースを保守可能に保つためにどのパターンを使用できるかについて詳しく説明します。 その後、アプリケーション レイヤー、ドメインを正確に使用する方法、ビュー モデルなどを使用して既存の Laravel の概念を改善する方法について説明します。
カバーする領域はたくさんあります。これからすぐに実践できる多くのことを学んでいただければ幸いです。