== システムの設計

実際、main関数のみ定義し、そこにすべてを定義したmain.rsファイルのみで本番稼働させているシステムは限りなく0に近い。
main関数は数行書き、最小限の責務を担う関数を複数定義してそれらを組み合わせて成り立たせるのが一般的だろう。
変数名$x$や$y$ではなく、わかりやすい英語を使うだろう。
もちろん、main関数にすべて書いた巨大なmain関数でも、変数名$a,b,c$だらけでも同じ挙動はするのだが、様々な問題がある。

- 作者（コーダー）が離職・入院・異動したとき
- 障害が発生したとき
- リファクタリングを実施するとき

上記のような"保守開発"フェーズでは、なにより保守性がキーとなる。
誰が読んでも、同じような改修の仕方になるような、そしてすぐ理解できるようなものがいいのである。
保守性が高いシステムは何か起きてもエラーの種類によってはすぐ改修することができるだろう。
これは運用サービスの品質に直結する。

品質のために保守性を担保するのは当然のことなのだが、それ以前にSEとしてのマナーでもあってほしい。
誰かが保守に困るようなものを世にリリースするべきではない。
また、業種にもよるが、感覚的に殆どのSEという職種はプロジェクト単位で参画したり退却したりする。
転職が珍しくない環境下で、同じ担当者が何年も同じ会社にいると思わない方が良い。

さて、設計論は１つのベストプラクティスがあるわけではなく、複数存在する。
ここではその中の１つのみ案内する。

== クリーンアーキテクチャへの招待

ドメインモデル、ユースケース、プレゼンテーションに分かれる。
これらは輪となり、変更が少ない情報ほど内に配置される。

ドメインモデルは設計の核であり、そのシステムを開発することになった発端でもある。
この核はシステム開発となんら関係ない普遍的なものになり、一般にビジネスロジックという。
例えば、「じゃんけんではグーがチョキに勝つ」等の情報レベルで、ここに変更を入れることはできない。
システム仕様ではなく、原則や規則にあたる。

ユースケースは、ドメインモデルを取扱い、ユーザ（クライアント）からの指令を果たす。
例えば、チョキとグーという二つの入力を受け取り、どちらが勝者なのか判定を返却する。
ただし、ユースケース自身は「チョキよりグーの方が強い」ことに関心は無く、あくまでドメインモデルに問合せているに過ぎない。
また、問合せ結果を返却する責務に留まり、クライアントに対して直接「勝ちました/負けました」を表示するのは、プレゼンテーションが担当する。

プレゼンテーションは常にクライアントと対峙している。
フォントサイズ、色、位置、テキスト入力など、システムとユーザが接する窓口（インターフェース）である。
飲食店の場合、ホールがプレゼンテーション、料理をマニュアル通りに調理するキッチンがユースケース、料理そのものがドメインモデルに相当する。

実際の開発プロセスでは、より複雑な概念や抽象的な事象を捉えていく必要があるため、ここではざっくりとした説明に留めた。
エンティティと値オブジェクト、ドメイン貧血、インフラストラクチャー層や依存性逆転の法則にまだ触れていないため、じゃんけんや飲食店の例は当たらずといえども遠からずである.
それぞれの責務ごとに明確にレイヤーを隔離することにより、テスタビリティや保守性を担保する。
