add ja translations

Author: Solant

astro.config.mjs

@@ -112,22 +112,22 @@ export default defineConfig({
             ru: '🍰 О нас',
           },
           items: [{
-            label: 'Mission',
-            translations: {
-              ru: 'Миссия',
-            },
+            // label: 'Mission',
+            // translations: {
+            // ru: 'Миссия',
+            // },
             slug: 'docs/about/mission'
           }, {
-            label: 'Motivation',
-            translations: {
-              ru: 'Мотивация',
-            },
+            // label: 'Motivation',
+            // translations: {
+            // ru: 'Мотивация',
+            // },
             slug: 'docs/about/motivation'
           }, {
-            label: 'Alternatives',
-            translations: {
-              ru: 'Альтернативы',
-            },
+            // label: 'Alternatives',
+            // translations: {
+            // ru: 'Альтернативы',
+            // },
             slug: 'docs/about/alternatives'
           }, {
             label: 'Understanding',

src/content/docs/ja/docs/about/alternatives.mdx

@@ -0,0 +1,88 @@
+---
+title: 代替案
+sidebar:
+  order: 3
+  badge:
+    text: WIP
+    variant: caution
+---
+
+import { FileTree } from '@astrojs/starlight/components';
+
+## ビッグボールオブマッド
+
+- [(記事) DDD - Big Ball of mud](https://thedomaindrivendesign.io/big-ball-of-mud/)
+
+
+## スマート＆ダムコンポーネント
+
+- [(記事) Dan Abramov - Presentational and Container Components (TLDR: 非推奨)](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)
+
+
+## デザイン原則
+
+## DDD
+
+## 参照 \{#see-also}
+
+- [(記事) DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together](https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/)
+
+## クリーンアーキテクチャ
+
+- [(記事) DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together](https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/)
+
+## フレームワーク
+
+- [(記事) FSDの作成理由 (フレームワークに関する断片)](/docs/about/motivation)
+
+
+## Atomic Design
+
+### これは何か？
+
+アトミックデザインでは、責任の範囲が標準化された層に分かれています。
+
+アトミックデザインは**5つの層**に分かれます（上から下へ）。
+
+1. `pages` - FSDの`pages`層と同様の目的を持つ。
+2. `templates` - コンテンツに依存しないページの構造を定義するコンポーネント。
+3. `organisms` - ビジネスロジックを持つ分子から構成されるモジュール。
+4. `molecules` - 通常、ビジネスロジックを持たないより複雑なコンポーネント。
+5. `atoms` - ビジネスロジックを持たないUIコンポーネント。
+
+同じ層のモジュールは、FSDのように下の層のモジュールとだけ相互作用しています。
+つまり、分子（molecule）は原子（atom）から構築され、生命体（organism）は分子から、テンプレート（template）は生命体から、ページ（page）はテンプレートから構築されます。
+また、アトミックデザインはモジュール内での**公開API**の使用を前提としています。
+
+### フロントエンドでの適用性
+アトミックデザインはプロジェクトで比較的よく見られます。アトミックデザインは、開発者の間というより、ウェブデザイナーの間で人気です。ウェブデザイナーは、スケーラブルでメンテナンスしやすいデザインを作成するためにアトミックデザインをよく使用しています。 
+開発では、アトミックデザインは他のアーキテクチャ設計方法論と混合されることがよくあります。
+
+しかし、アトミックデザインはUIコンポーネントとその構成に焦点を当てているため、 
+アーキテクチャ内でビジネスロジックを実装する問題が発生してしまいます。
+
+問題は、アトミックデザインがビジネスロジックのための明確な責任レベルを提供していないため、 
+ビジネスロジックがさまざまなコンポーネントやレベルに分散され、メンテナンスやテストが複雑になることです。 
+ビジネスロジックは曖昧になり、責任の明確な分離が困難になり、コードがモジュール化されず再利用可能でなくなります。
+
+### FSDとの統合
+FSDの文脈では、アトミックデザインのいくつかの要素を使用して柔軟でスケーラブルなUIコンポーネントを作成することができます。 `atoms`と`molecules`の層は、FSDの`shared/ui`に実装でき、基本的なUI要素の再利用とメンテナンスを簡素化しています。
+
+<FileTree>
+- shared/
+  - ui/
+    - atoms/
+    - molecules/
+</FileTree>
+
+FSDとアトミックデザインの比較は、両方の設計方法論がモジュール性と再利用性を目指していることを示していますが、 
+異なる側面に焦点を当てています。アトミックデザインは視覚的コンポーネントとその構成に焦点を当てています。 
+FSDはアプリケーションの機能を独立したモジュールに分割し、それらの相互関係に焦点を当てています。
+
+- [Atomic Design](https://atomicdesign.bradfrost.com/table-of-contents/)
+- [(動画) Atomic Design: What is it and why is it important?](https://youtu.be/Yi-A20x2dcA)
+
+## Feature Driven
+
+- [(講演) Feature Driven Architecture - Oleg Isonen](https://youtu.be/BWAeYuWFHhs)
+- [Feature Driven-Short specification (from the point of view of FSD)](https://github.com/feature-sliced/documentation/tree/rc/feature-driven)

src/content/docs/ja/docs/about/mission.mdx

@@ -0,0 +1,50 @@
+---
+title: ミッション
+sidebar:
+  order: 1
+---
+
+ここでは、私たちがFSD方法論を開発する際に従う方法論適用の制限と目標について説明します。
+
+- 私たちは、目標をイデオロギーとシンプルさのバランスとして考えている
+- 私たちは、すべての人に適した銀の弾丸を作ることはできない
+
+**それでも、FSD方法論が広範な開発者にとって近く、アクセス可能であることを望んでいます。**
+
+## 目標 \{#goals}
+
+### 幅広い開発者に対する直感的な明確さ \{#intuitive-clarity-for-a-wide-range-of-developers}
+
+FSD方法論は、プロジェクトチームの大部分にとってアクセス可能であるべきです。
+
+*なぜなら、将来のすべてのツールがあっても、FSD方法論を理解できるのは経験豊富なシニアやリーダーだけでは不十分だからである*
+
+### 日常的な問題の解決 \{#solving-everyday-problems}
+
+FSD方法論には、プロジェクト開発における日常的な問題の理由と解決策が示されるべきです。
+
+また、開発者が*コミュニティーの経験に基づいた*アプローチを使用できるようにし、長年のアーキテクチャや開発の問題を回避できるようにするには、**FSD方法論はこれに関連するツール（CLI、リンター）を提供することも必要です。**
+
+
+> *@sergeysova: 想像してみてください。開発者が方法論に基づいてコードを書いているとき、開発者の直面している問題は10倍少なく発生しています。それは他の人々が多くの問題の解決策を考え出したから、可能になったのです。*
+
+## 制限 \{#limitations}
+
+私たちは*自分たちの見解を押し付けたくありません*が、同時に*多くの開発者の習慣が日々の開発の妨げになっていることを理解しています。*
+
+すべての開発者にはシステム設計と開発経験レベルが異なるため、**次のことを理解することが重要です。**
+
+- FSD方法論は、すべての開発者にとって、同時に非常にシンプルで、非常に明確にするのは不可能
+    > *@sergeysova: 一部の概念は、問題に直面し、解決に数年を費やさない限り、直感的に理解することはできない。*
+    >
+    > - *数学の例 — グラフ理論。*
+    > - *物理の例 — 量子力学。*
+    > - *プログラミングの例 — アプリケーションのアーキテクチャ。*
+    >
+- シンプルさ、拡張性は、実現可能であって望ましい
+
+## 参照 \{#see-also}
+
+- [アーキテクチャの問題][refs-architecture--problems]
+
+[refs-architecture--problems]: /docs/about/understanding/architecture#problems

src/content/docs/ja/docs/about/motivation.mdx

@@ -0,0 +1,132 @@
+---
+title: モチベーション
+sidebar:
+  order: 1
+---
+
+**Feature-Sliced Design**の主なアイデアは、さまざまな開発者の経験を議論し、研究結果を統合することに基づいて、複雑で発展するプロジェクトの開発を容易にし、開発コストを削減することです。
+
+明らかに、これは銀の弾丸ではなく、当然ながら、FSDには独自の[適用範囲の限界][refs-mission]があります。
+
+## 既存の解決策が不足している理由 \{#intuitive-clarity-for-a-wide-range-of-developers}
+> 通常、次のような議論があります。
+>
+> - *「SOLID」、「KISS」、「YAGNI」、「DDD」、「GRASP」、「DRY」など、すでに確立された設計原則があるのに、なぜ新しい方法論が必要なのか？」*
+> - *「プロジェクトのすべての問題は、良いドキュメント、テスト、確立されたプロセスで解決できる」*
+> - *「すべての問題は、すべての開発者が上記のすべてに従えば解決される」*
+> - *「すでにすべてが考案されているから、あなたはそれを利用できないだけだ」*
+> - *\{FRAMEWORK_NAME\}を使えば、すべてが解決される」*
+
+### 原則だけでは不十分 \{#principles-alone-are-not-enough}
+
+**良いアーキテクチャを設計するためには、原則の存在だけでは不十分です。**
+
+すべての人が原則を完全に理解しているわけではありません。正しく原則を理解し、適用できる人はさらに少ないです。
+
+*設計原則はあまりにも一般的であり、「スケーラブルで柔軟なアプリケーションの構造とアーキテクチャをどのように設計するか？」という具体的な質問に対する答えを提供していません。*
+
+### プロセスは常に機能するわけではない \{#processes-dont-always-work}
+
+*ドキュメント/テスト/プロセス*を使用するのは、確かに良いことですが、残念ながら、それに多くのコストをかけても、**アーキテクチャの問題や新しい人をプロジェクトに導入する問題を解決することは常にできるわけではありません。**
+
+- ドキュメントは、しばしば膨大で古くなってしまうので、各開発者のプロジェクトへの参加時間はあまり短縮されない。
+- 誰もが同じようにアーキテクチャを理解しているかを常に監視することは、膨大なリソースを必要とする。
+- bus-factorも忘れないようにしましょう。
+
+### 既存のフレームワークはどこでも適用できるわけではない \{#existing-frameworks-cannot-be-applied-everywhere}
+
+- 既存の解決策は通常、高い参入障壁があるため、新しい開発者を見つけるのが難しい。
+- ほとんどの場合、技術の選択はプロジェクトの深刻な問題が発生する前に決定されているため、**技術に依存せずに**、すでにあるもので作業をすることができなければならない。
+
+> Q: *「私のプロジェクトでは`React/Vue/Redux/Effector/Mobx/{YOUR_TECH}`を使っていますが、エンティティの構造とそれらの間の関係をどのように構築すればよいでしょうか？」*
+
+### 結果として \{#as-a-result}
+
+「雪の結晶」のようにユニークなプロジェクトが得られ、それぞれが従業員の長期的な関与を必要とし、他のプロジェクトではほとんど適用できない知識を必要とします。
+
+> @sergeysova: *これは、現在のフロントエンド開発の状況そのものであり、各リーダーがさまざまなアーキテクチャやプロジェクトの構造を考案しているが、これらの構造が時間の試練に耐えるかどうかは不明であり、最終的にはリーダー以外の人がプロジェクトを発展させることができるのは最大で2人であり、新しい開発者を再び入れる必要がある。*
+
+## 開発者にとっての方法論の必要性 \{#why-do-developers-need-the-methodology}
+
+### アーキテクチャの問題ではなくビジネス機能に集中するため \{#focus-on-business-features-not-on-architecture-problems}
+
+FSDは、スケーラブルで柔軟なアーキテクチャの設計にかかるリソースを節約し、開発者の注意を主要な機能開発に向けることを可能にしています。同時に、プロジェクトごとにアーキテクチャの解決策も標準化されます。
+
+*別の問題は、FSDがコミュニティの信頼を得る必要があることです。そうすれば、開発者は自分のプロジェクトの問題を解決する際に、与えられた時間内にFSDを理解し、信頼することができます。*
+
+### 経験に基づく解決策 \{#an-experience-proven-solution}
+
+FSDは、*複雑なビジネスロジックの設計における経験に基づく解決策を目指す開発者*を対象としています。
+
+*ただし、FSDは、全体としてベストプラクティスのセット、または特定の問題やケースに関する記事一覧です。したがって、開発や設計の問題に直面する他の開発者にも役立てます。*
+
+### プロジェクトの健康 \{#project-health}
+
+FSDは、*プロジェクトの問題を事前に解決し、追跡することを可能にし、膨大なリソースを必要としません。*
+
+**技術的負債は通常、時間とともに蓄積され、その解決の責任はリーダーとチームの両方にあります。**
+
+FSDは、*スケーリングやプロジェクトの発展における潜在的な問題を事前に警告することを可能にしています。*
+
+## ビジネスにとってのFSD方法論の必要性 \{#why-does-a-business-need-a-methodology}
+
+### 迅速なオンボーディング \{#fast-onboarding}
+
+FSDを使用すると、**すでにこのアプローチに慣れている人をプロジェクトに雇うことができ、再教育する必要がありません。**
+
+*人々はより早くプロジェクトに慣れ、貢献し始め、次のプロジェクトのイテレーションで人を見つけるための追加の保証が得られます。*
+
+### 経験に基づく解決策 \{#an-experience-proven-solution-1}
+
+ビジネスは、プロジェクトの発展における大部分の問題を解決するフレームワーク/解決策を得たいと考えています。FSDにより、ビジネスは*システムの開発中に発生するほとんどの問題に対する解決策を得ることができます。*
+
+### プロジェクトのさまざまな段階への適用性 \{#applicability-for-different-stages-of-the-project}
+
+FSDは、*プロジェクトのサポートと発展の段階でも、MVPの段階でもプロジェクトに利益をもたらすことができます。*
+
+はい、MVPでは通常、<i>機能が重要であり、将来のアーキテクチャは重要ではありません</i>。しかし、限られた時間の中で、方法論のベストプラクティスを知っていることで、<i>少ないコストで済む</i>ことができ、MVPバージョンのシステムを設計する際に合理的な妥協を見つけることができます（無計画に機能を追加するよりも）。
+
+*テストについても同じことが言えます。*
+
+## 私たちの方法論が必要ない場合 \{#when-is-our-methodology-not-needed}
+
+- プロジェクトが短期間しか存続しない場合
+- プロジェクトがサポートされるアーキテクチャを必要としない場合
+- ビジネスがコードベースと機能の提供速度の関連性を認識しない場合
+- ビジネスができるだけ早く注文を完了することを重視し、さらなるサポートを求めない場合
+
+### ビジネスの規模 \{#business-size}
+
+- **小規模ビジネス** - 通常、迅速で即効性のある解決策を必要とします。ビジネスは、成長する（少なくとも中規模に達する）と、顧客が継続的にサービスなどを利用するためには、開発される解決策の品質と安定性に時間をかける必要があることを理解し始めます。
+- **中規模ビジネス** - 通常、開発のすべての問題を理解しており、たとえ機能をできるだけ早くリリースしたい場合でも、品質の改善、リファクタリング、テスト（そしてもちろん、拡張可能なアーキテクチャ）に時間をかけます。
+- **大規模ビジネス** - 通常、すでに広範なオーディエンスを持ち、従業員の数も多く、独自のプラクティスのセットを持っているため、他のアプローチを採用するアイデアはあまり浮かびません。
+
+## 目標 \{#plans}
+
+主要な目標の大部分は[ここに記載されています][refs-mission--goals]が、今後のFSD方法論に対する私たちの期待についても話しておく必要があります。
+
+### 経験の統合 \{#combining-experience}
+
+現在、私たちは`core-team`のさまざまな経験を統合し、実践に基づいた方法論を得ることを目指しています。
+
+もちろん、最終的にはAngular 3.0のようなものを得るかもしれませんが、ここで最も重要なのは、**複雑なシステムのアーキテクチャ設計の問題を探求することです。**
+
+*そして、現在のFSD方法論のバージョンに対して不満があることは確かですが、私たちはコミュニティの経験も考慮しながら、共通の努力で統一的かつ最適な解決策に到達したいと考えています。*
+
+### 仕様外の生活 \{#life-outside-the-specification}
+
+すべてがうまくいけば、FSDは仕様やツールキットに限定されることはありません。
+
+- 講演や記事があるかもしれない。
+- FSD方法論に従って書かれたプロジェクトの他の技術への移行のための`CODE_MODEs`があるかもしれない。
+- 最終的には、大規模な技術的解決策のメンテイナーに到達できるかもしれない。
+  - *特にReactに関しては、他のフレームワークと比較して、これは主な問題である。なぜなら、特定の問題を解決する方法を示さないからである。*
+
+## 参照 \{#see-also}
+
+- [方法論の使命について：目標と制限][refs-mission]
+- [プロジェクトにおける知識の種類][refs-knowledge]
+
+[refs-mission]: /docs/about/mission
+[refs-mission--goals]: /docs/about/mission#goals
+[refs-knowledge]: /docs/about/understanding/knowledge-types

src/content/docs/ja/docs/about/promote/integration.mdx

@@ -0,0 +1,18 @@
+---
+title: 統合の側面
+sidebar:
+  order: 1
+---
+
+# 統合の側面
+
+**利点**:
+- [概要](/docs/get-started/overview#advantages)
+- コードレビュー
+- オンボーディング
+
+**欠点**:
+- メンタル的な複雑さ
+- 高い参入障壁
+- 「レイヤー地獄」
+- 機能ベースのアプローチにおける典型的な問題