スライスとセグメント

スライス

スライスは、Feature-Sliced Designの組織階層の第２レベルです。主な目的は、プロダクト、ビジネス、または単にアプリケーションにとっての意味に基づいてコードをグループ化することです。

スライスの名前は標準化されていません。なぜなら、それらはアプリケーションのビジネス領域によって直接決定されるからです。たとえば、フォトギャラリーには photo、effects、gallery-page というスライスがあるかもしれません。SNSには、post、comments、news-feed などの別のスライスが必要です。

Shared層とApp層にはスライスが含まれていません。これは、Sharedがビジネスロジックを含むべきではないため、プロダクト的な意味を持たないからです。また、Appはアプリケーション全体に関わるコードのみを含むべきであり、したがって分割は必要ありません。

低結合と高凝集

スライスは、独立した強く凝集しているコードファイルのグループとして設計されています。以下の図は、凝集（cohesion）と結合（coupling）といった複雑な概念を視覚化するのに役立ちます。

この図は、https://enterprisecraftsmanship.com/posts/cohesion-coupling-difference/ に触発されています。

理想的なスライスは、同じレベルの他のスライスから独立しており（低結合）、その主な目的に関連するコードの大部分を含んでいます（高凝集）。

スライスの独立性は、層のインポートルールによって保証されます。

スライス内のモジュール（ファイル）は、厳密に下の層にあるスライスのみをインポートできます。

スライスの公開APIルール

スライス内では、コードは自由に整理できますが、スライスが質の高い公開APIを持っている限り、問題はありません。これがスライスの公開APIのルールの本質です。

各スライス（およびスライスを持たない層のセグメント）は、公開APIの定義を含む必要があります。

あるスライス/セグメントの外部モジュールは、そのスライス/セグメントの内部ファイル構造ではなく、公開APIのみを参照できます。

公開APIの要求の理由や、作成のベストプラクティスについては、公開APIのガイドを参照してください。

スライスのグループ

密接に関連するスライスは、フォルダに構造的にグループ化できますが、他のスライスと同じ隔離ルールを遵守する必要があります。グループ化用のフォルダ内でのコードの共有は許可されていません。

セグメント

セグメントは、組織階層の第３および最後のレベルであり、その目的は、技術的な目的に基づいてコードをグループ化することです。

いくつかの標準化されたセグメント名があります。

• ui — UIに関連するすべてのもの：UIコンポーネント、日付フォーマッタ、スタイルなど。
• api — バックエンドとのインタラクション：リクエスト関数、データ型、マッパーなど。
• model — データモデル：スキーマ、インターフェース、ストレージ、ビジネスロジック。
• lib — スライス内のモジュールに必要なライブラリコード。
• config — 設定ファイルとフィーチャーフラグ。

レイヤーに関するページには、これらのセグメントが異なる層でどのように使用されるかの例があります。

独自のセグメントを作成することもできます。カスタムセグメントの最も一般的な場所は、スライスが意味を持たないApp層とShared層です。

これらのセグメントの名前が、その内容が何のために必要かを説明するものであることを確認してください。たとえば、components、hooks、types は、コードを探すときにあまり役に立たないため、悪いセグメント名です。