この記事ではBEAR固有の話題はあまり出てきませんが、私がBEARアプリケーションを作るときに考えていることについて書きます。
はじめに
BEAR.Resource はアプリケーションの情報や機能をリソースにしてREST制約で結びます[※1]。
実務の実装では、下図のようにリソースがフレームワークファミリのコンポーネント（例：フォーム）やドメイン固有のビジネスコンポーネントに依存する形になることがほとんどでしょう。
[リソース] -- depends --> [フレームワークファミリのコンポーネント] or [ビジネスコンポーネント]
ユーザの皆さん、ディレクトリ構成はどうされていますでしょうか。例として、
「商品を注文するショッピングサイトを作る」
というお題で考えてみます。
方法１：コンテキスト境界をディレクトリとする
この例で、前回の記事で私はこのように作ってみました（しかし、ほとんどの人はまずこうはしないですよね。いかがでしょうかね？！）
リソースと同階層のトップレベルにビジネスコンポーネントのルートを置きました（ビジネス名が"Example"なのが分かりづらいですが、ここに固有のパッケージ名が入るイメージです。）。下図のように、コンテキストごとにフレームワークファミリの構成要素（Formの具象クラスなど）や自作のビジネスコンポーネントがぶら下がります。
- 特徴：業務を垂直的に管理していくことで、複雑さに耐えやすい
方法２：フレームワークの提供する型（構成要素）をそのままディレクトリにする
フレームワークの学習教材としてはこちらの方法の方が直感的で分かりやすいでしょう。
こちらは基盤の型ベースで水平的な見方かと思います。
（※余談ですが、DDD本を学習した人がトップレベルに[Domain]というディレクトリを置いて型ごとにディレクトリを分けている例をよく見ますが、それも分類としてはこちらになると思います。）
おわりに
ともあれ、ディレクトリ構成というのは一度アプリケーションを作ってしまうと後からは変えづらい箇所ですから、設計対象として最初に考える必要があり、議論の余地があるところかと思います。
引用記事
- [※1] BEARマニュアル -リソース
[2022年5月追記 ここから]
- 関連リンク