docs/guide-ja/structure-models.md - small changes [ci skip]

docs/guide-ja/structure-models.md

@@ -470,18 +470,18 @@ public function fields()
 ## 最善の慣行<a name="best-practices"></a>
 
 モデルは、業務のデータ、規則、ロジックを表わす中心的なオブジェクトです。
-モデルは、他の場所で再利用する必要がよくあります。
+モデルは、さまざまな場所で再利用される必要がよくあります。
 良く設計されたアプリケーションでは、通常、モデルは [コントローラ](structure-controllers.md) よりもはるかに重いものになります。
 
 要約すると、モデルは、
 
-* ビジネスデータを表現する属性を含むことが出来る;
-* データの有効性と整合性を保証する検証規則を含むことが出来る;
-* ビジネスロジックを実装するメソッドを含むことが出来る;
-* リクエスト、セッション、または他の環境データに直接アクセスするべきではない。
-  これらのデータは、[コントローラ](structure-controllers.md) によってモデルに注入されるべきである;
-* HTML を埋め込むなどの表示用のコードは避けるべきである - これは [ビュー](structure-views.md) で行う方が良い;
-* あまりに多くの [シナリオ](#scenarios) を単一のモデルで持つことは避ける。
+* ビジネスデータを表現する属性を含むことが出来ます;
+* データの有効性と整合性を保証する検証規則を含むことが出来ます;
+* ビジネスロジックを実装するメソッドを含むことが出来ます;
+* リクエスト、セッション、または他の環境データに直接アクセスするべきではありません。
+  これらのデータは、[コントローラ](structure-controllers.md) によってモデルに注入されるべきです;
+* HTML を埋め込むなどの表示用のコードは避けるべきです -  表示は [ビュー](structure-views.md) で行う方が良いです;
+* あまりに多くの [シナリオ](#scenarios) を単一のモデルで持つことは避けましょう。
 
 大規模で複雑なシステムを開発するときには、たいてい、上記の最後にあげた推奨事項を考慮するのが良いでしょう。
 そういうシステムでは、モデルは数多くの場所で使用され、それに従って、数多くの規則セットやビジネスロジックを含むため、非常に大きくて重いものになり得ます。
@@ -489,11 +489,11 @@ public function fields()
 モデルのコードの保守性を高めるために、以下の戦略をとることが出来ます:
 
 * 異なる [アプリケーション](structure-applications.md) や [モジュール](structure-modules.md)
-  によって共有される一連の基底モデルクラスを定義する。
-  これらのモデルクラスは、すべてで共通に使用される最小限の規則セットとロジックのみを含むべきである。
+  によって共有される一連の基底モデルクラスを定義します。
+  これらのモデルクラスは、すべてで共通に使用される最小限の規則セットとロジックのみを含むべきです。
 * モデルを使用するそれぞれの [アプリケーション](structure-applications.md) または [モジュール](structure-modules.md) において、
-  対応する基底モデルクラスから拡張した具体的なモデルクラスを定義する。
-  この具体的なモデルクラスが、そのアプリケーションやモジュールに固有の規則やロジックを含むべきである。
+  対応する基底モデルクラスから拡張した具体的なモデルクラスを定義します。
+  この具体的なモデルクラスが、そのアプリケーションやモジュールに固有の規則やロジックを含むべきです。
 
 例えば、[アドバンストアプリケーションテンプレート](tutorial-advanced-app.md) の中で、
 基底モデルクラス `common\models\Post` を定義することが出来ます。