読んだ本の紹介

心理学とUXに関する本を読みました。

読んだ本：UXデザインの法則

UXデザインの法則 ―最高のプロダクトとサービスを支える心理学 | Jon Yablonski, 相島雅樹, 磯谷拓也, 反中望, 松村草也 |本 | 通販 | Amazon

この本は、システムにおける一般的なUI✖UX関連の事柄について、当たり前と思えるところを心理学的背景や実際の事例に基づいて説明されている。

なので、新しいUIのヒントを得ることが出来る本というより、今あるシステムは心理学的背景をもってして生まれたものなんだよ　って記載の方がメイン。手軽にUI改善のヒントを得るというよりは、それよりももっと理論（根本）の話に近い。かつソフトウェア的な話だけでなく、ハード的な話も多かった。

手軽にUI改善のヒントを得ることが出来るサイトとしてこのサイトが好き：UIデザインのための心理学：33の法則・原則（実例つき） | ベイジのUIラボ～業務システムとSaaSのUIを考える (baigie.me)

SEなら必読サイトだよ。

読んで面白かったとこ

心理学的に、「カジノのスロットマシーン」と「Twitterのタイムライン」は同じ仕組みらしい。
カジノのスロットマシーンは、だれが今どんな状況にいるのかをすべて記録している。その人がかけた金額と当たった金額をすべて記憶していて負けがかさんだぎりぎりのとこで当たりを上げてドーパミンを出す。レバーを無心で引いてたまに当たる。それを繰り返させる。
Twitterのタイムラインも同様で更新には引くアクションを取らせる。たまに新しい投稿が出る。Twitterのタイムラインの構成はスロットの中毒性と似ているらしい（知らんけどわりと面白い考えだった）（オペラント条件付け）
ユーザはデフォルトを信じ切る。自分の思った通りの設定じゃなくても「それがデフォルト」だからというだけの理由で変更しないらしい。悪さに使えてしまうからシステム設計ではユーザ補助でデフォルトを使うことがあろうが、悪いことで使ってはならない。信頼を失うよ。
デザインには倫理が伴わなければならない。最近のWebサイトは「サイト滞在時間を増やしたい、メディア広告を見させたい、価値ある情報を抜き出したい」という商業的な思惑が蔓延している。本来、システムやデザインはユーザの価値ある体験を支援するものでなければならない。通販サイトで「残り○点のみ」と出して購買意欲を掻き立てるのは商業的な考えであってその人が本当に欲しいとは限らないんだよ

本の内容

ヤコブの法則

ユーザは他のサイトで多くの時間を費やしているので、あなたのサイトにもそれらと同じ挙動をするように期待している

ユーザが慣れ親しんだプロダクトと見た目が似ていれば、同じように動くことを期待される
すでにあるメンタルモデルを活かせば、ユーザは新たなメンタルモデルの学習なしにタスクに集中でき、ユーザ体験の質が高まる
変更時の違和感を最小限にとどめるためには、慣れ親しんだバージョンを使い続けられる移行期間を設けよう

Youtubeなんかは、新デザインをリリースする際は、ユーザに新デザインのまま利用するか旧デザインに戻すかを選択させるようにしている

フィッツの法則

ターゲットに至るまでの時間はターゲットの大きさと近さで決まる

タッチターゲットにはユーザが正確に推せるための十分な大きさが必要
タッチターゲット同士には十分は距離を開ける
タッチターゲットはインタフェース内で、ユーザが簡単に到達できる場所になければならない

⇒つまりボタンは十分な大きさがなければならないし、ボタン同士は誤タップがないように十分な感覚がなければならない。入力した後の下部にボタンがなければならない。

ヒックの法則←大事

意思決定にかかる時間はとりうる選択肢の数と複雑さで決まる

応答に時間がかかって意思決定が遅くなってるときは選択肢を最小限にまで減らす
タスクが複雑なら、小さなステップに分けて認知負荷を下げる
ユーザが情報量に圧倒されないようにおすすめの選択肢を目立たせる
段階的なオンボーディングを採用し、新規ユーザの認知負荷を最小限にする
単純化によって抽象的になりすぎないようにする

TVリモコンは機能を持ちすぎてしまったため、老人用に機能を限定してあげる。
Googleは検索をした後にどのコンテンツを観たいかを後から選べる

ミラーの法則

普通の人が短期記憶に保持できるのは7(+-2)個まで

マジカルナンバー7の数字に惑わされて無用なデザイン制約を作らない
コンテンツを小さなチャンクに分けることで、ユーザがその情報を扱い、理解し、記憶しやすくできる
短期記憶の容量は、個々人が持っている知識や状況、文脈によって大きく幅がある

ここで大事な記述は、人間はチャンク（まとまり）で記憶するということ。

例えば「098675309」という文字列と「(09)867-5309」の文字列では、後者の方が覚えやすいということ。電話番号の書式。

文字（アルファベットやひらがな）7つと、単語7つでは同じくらいの負荷で記憶ができるということ。人間は長さよりまとまりで記憶する。

よって、平らな文よりヘッダーなどのタイトル、書式設定、階層構造を用いて簡単に記憶を補助できる。

ポステルの法則

出力は厳密に、入力には寛容に

ユーザがとりうるアクションや、入力しうる情報すべてに対して理解を示し柔軟に対応し寛容になる
信頼性高くアクセス可能なインタフェースを提供しながら、入力、アクセス、および機能の面で実際に起こりうるあらゆることを予測する
予測・対応できることが多ければ多いほどデザインはより柔軟になる
ユーザからの多様な入力を受け入れ、それを要件に合わせて変換し、入力の境界線を定義し、ユーザに明確なフィードバックを提供する

⇒ハードウェアにとらわれないレスポンシブなデザインをする

ピークエンドの法則

経験についての評価は、全体の総和や平均ではなく、ピーク時と終了時にどう感じたかで決まる。

ユーザジャーニーの中で最も重要な瞬間（ピーク）と最後の瞬間（エンド）に細心の注意を払う
エンドユーザを喜ばせるためには、プロダクトが最も役立つ瞬間、最も価値がある瞬間、あるいは最も楽しい瞬間を見定めてデザインする
人はポジティブな経験よりも、ネガティブな経験をより鮮明に思い出す

Ubereatsとかは、商品が届くまでの退屈な時間を安心させるためにルートや到着時間を利用者に伝えている。

美的ユーザビリティ効果

見た目が美しいデザインはより使いやすいと感じられる

見た目が美しいデザインは、人の脳にポジティブな反応をもたらし、実際の場面でもよく機能すると受け取られる
プロダクトやサービスの見た目が美しければ、人は些細なユーザビリティの問題に対してより寛容になる
見た目が美しいデザインはユーザビリティの問題を覆い隠し、ユーザビリティテスト中に課題を発見しにくくしてしまう

フォンレストルフ効果

似たものが並んでいると、その中で他とは異なるものが記憶に残りやすい

重要な情報やアクションを視覚的に目立たせる
視覚的な要素を強調する際には、互いに競合したり、目立ちすぎて広告だと勘違いされないように抑制する
コントラストを伝えるのを色だけに頼ると、色覚障がい者やロービジョンを排除することになる
コントラストを伝えるうえで動きを使用する際には、動きに対し敏感なユーザに配慮する

テスラ―の法則

どんなシステムにもそれ以上に減らすことのできない複雑さがある。複雑性保存の法則

どんなプロセスにもその核となる部分にはデザインの工夫をもってしても取り除くことのできない複雑性を抱えている。この複雑性による負荷を追うのはシステムかユーザか
この固有の複雑性をデザインと開発の過程でどうにかしながらできる限りユーザ負荷を減らす
シンプルにしすぎてインタフェースが抽象的になりすぎていないかを気にする

例えばメール送信には、メール送信者、宛先、メール本文という絶対に必要かつこれ以上減らせないめんどうくささがある。これは送信者を利用者本人にしたり、宛先のメアドを途中入力したらサジェストしてあげたり、本文の候補をシステムが考えてあげたりシステムが手助けすることが出来る。

住所入力で、郵便番号を入れるだけでプリセットしてあげるとかもこれ

ドハティの閾値

応答が0.4秒以内のとき、コンピュータとユーザ双方でもっとも生産的になる

0.4秒以内にフィードバックを行うことで、ユーザの注意を惹きつけ、生産性を高める
体感性能を改善し、感じられる待ち時間を減らす
アニメーションを入れることで、バックグラウンドで読み込みや処理が行われている間もユーザをつなぎとめる
プログレスバーは正確であってなくても待ち時間へのいらだちを和らげる
ほとんど処理時間がかかっていない場合でも、意図的に遅延させることで体感性能が改善して信頼感の醸成になる

読み込み時間は画面を先に展開しつつも、コンテンツが表示されるまでの時間はスケルトンスクリーンを表示する。

そのほかの心理学

オペラント条件付け
断続的変動報酬
- Twitterのタイムライン的なたまに報酬を受け取れる仕組み
無限ループ
- YouTube的なずっと動画を流す
社会的肯定感
- いいね機能
デフォルト
- サービスを利用し始めたときにデフォルト設定から変更をしない
摩擦を取り除く
- なにか面倒なことがボタン一つで解決されるならそれを利用する
返報性
- 他者から返事を求められるような通知が来ると、返さざるを得ない
ダークパターン
- ユーザにとっての利益ではなく、システム提供者の利益になるようにシステムをデザインすること

そのほかの出てきたやつ

目標勾配効果

目標へ近づくにつれ、さらに目標を達成しやすくなる。

共域の法則

明確に境界が定められた領域を共有する要素は、グループとして知覚されやすい

近接性の法則

近くにある、ないし、お互いに接する対象は、同じグループとして知覚されやすい

プレグナンツの法則

曖昧ないし複雑なイメージは、できるかぎり簡潔な形態として受け取られやすい。そうすることで認知負荷を最小限に抑えられる。

類似性の法則

互いに類似した要素は、たとえそれがバラバラに配置されていたとしても、1つの絵、形、グループとして知覚される。

連続性の法則

視覚的に繋がった要素はつながりのない要素よりも関連性があると知覚されやすい

系列位置効果

系列の最初と最後の項目が最も記憶に残りやすい

ツァイガルニク効果

完了したタスクよりも未完了や中段したタスクの方が記憶に残りやすい

2024-05-08

名著：十角館の殺人を読みました

挨拶

どうも、文学少年です。

前回の投稿を行った翌日、日曜日から3日間をかけて綾辻行人先生の十角館の殺人を読みました。twitterで読んだって投稿しようと思ったのですが、ちょっとネタバレっぽいことも書きたく、こっちに書きます。

彼女がGW仕事でとにかく暇でした。

最初はネタバレなしの内容で書きますが下にめちゃくちゃスクロールするとネタバレが書いてある感じです。

読んだ本

十角館の殺人 (講談社文庫) | 綾辻行人 |本 | 通販 | Amazon

オタク特有の自分語り

綾辻先生の本は、Anotherのみ読んでいました。Anotherは私の中学時代のバイブルでオタクにたらしめた複数要因の一角です。Anotherの漫画版の作画担当をした清原紘先生をイラストレーターとして崇拝していましたので、その流れで買って読んではまった感じです。清原先生作画でAnother同様に十角館も漫画化していますので、小説読む人が億劫な人は適当な漫画サイトで漫画を読むのもいいと思います。

十角館はもちろん知っていましたが、大学時代の読書ブームで読まずにだらだら読んでいなかったら、今年の3月に高校の友達にめちゃくちゃ面白かったから読んでみと勧められ、社会人になるとなかなか小説を勧められることもないので買って読みました。

なんで5月までもつれこんだかというと、ちょっと4月いっぱいはやらなければいけないことがあったので、それが片付いたGWを使って読みました。だから最近やたらとコメダ珈琲に入り浸っては本を爆読みしているのです。

あらすじ

あらすじはちゃんとした本の背表紙を読むといいと思いますが、ネタバレにならないようになるべく興味を引けるように書きます。

あらすじは陸の孤島：角島にある正十角形の形をした建物：十角館に1週間滞在をする予定になった大学生男女7人に巻き起こる連続殺人事件です。
この島は半年前に島主を含めた4人の無理心中（？）と1人の使用人の行方不明という未解決事件がありました。この事件に興味を持った7人が角島に訪れるわけですが、そこで奇妙な殺害予告が行われます。7人中5人の殺害、その中の1人が犯人であるという内容です。

過去に起きた4人の死亡、1人の行方不明という未解決事件

現在、大学生7人に巻き起こっている連続殺人事件

この過去と現在の事件を、角島と遠く離れた本島との2つの場面からだんだんと解決していくというストーリーになっています。

（ネタバレではないよな・・・？）

登場人物の半分以上は死にますw

感想（ネタバレなし）

凄く面白かったです。前述のとおり島と本島との2つの場面から、今と過去の話をしていく、割と多次元的に話が進むため結構最初の方はじっくり読む必要がありました。登場人物と性格を覚えるのが結構大変でした。ただそれは最初の章だけでつかんだらすらすら読んでいけます。内容も読みやすいもの（時代小説のような古臭い文体ではない）です。

漫画、ドラマ、アニメ、映画とどうもその場面描写を提示してくるコンテンツが世の中には多いですし、そちらの方が情報を摂取するのが楽なのですが、やはり小説ならではの文だけでシチュエーションを想像する、というのはこの媒体にしか出せない楽しさだな、と改めて感じることが出来ます。（前述のとおり、十角館は漫画家もドラマ化もしています）
また、小説を読んでいて、自分が想像していたものと違う状況が急に説明される、1文読んだだけで、自分が今まで想像していたことが覆る、といった感覚はやはり映像作品などではできない表現の仕方で鳥肌が立ちます。まさしく十角館はそういった1文で読者を裏切るしかけが施されていてとても楽しいかったです。小説でぜひ読んでほしいと思える作品です。

小説ならではのトリック、です。

読むときはぜひ情景描写の想像の他に、人物像もよくイメージして楽しんだ方がいいです。○○君はこういうやつなんだな、というのを1人1人文から得た情報を覚え、想像することが楽しむポイントです。

以上、感想です。

下にスクロールすると、ネタバレをします。

あ

そろそろネタバレ書くよ

うんち

ネタバレ込みで書きます。

自分は結構推理小説を読んでいるときにある程度こいつが犯人かもなぁと想像して読みます。後、島田壮司先生が大好きなので舞台装置にトリックがあるのではと考えて読みます。

ですので

十角館の部屋割りがわかった後は誰かが死ぬたびにこの部屋割のにらめっこしてなんとなく考えていました。

最初に考え始めたのはオルツィとカーが死んだあとです。なんとなく十角形の対角線の2人が死んだのでこの対角線が大事かな？と考えていました。また、十角形で何が考えられるだろうか、内角、対角線くらいしか思いつかないですが、理系なりに考えを巡らせていた次第です。

最初に疑ったのはルルウでした。単純ですがルルウとカーは隣の部屋だったのでこの部屋の間に穴でもあけてカーの部屋に忍び込んだのではと馬鹿ながら考えていました。カーはホールでみんなの前で死んだのに。アガサは女の子って理由だけで犯人からは外しましたね。エピローグで男だとわかっていましたし。

ルルウとアガサが一緒に死んで、あっけなく予想は散りました。

さすがにエラリイは犯人じゃないだろうと思っていたので、ヴァンかポウですよね。ん～どちらもオルツィと部屋は隣接しているし、洗面所からも脱走できそうだよなぇと思ったり、結構予想は楽しかったです。

場面は変わって本島側のコナン君側ですが、さすがに絵をかきに行ってるモリスは怪しいなぁって思っていました。本島側は登場人物も少なかったですし。中村氏の弟（紅次郎でしたっけ？）はあからさますぎてまあないだろ、あるとしても関係者（十角館にいる犯人の共謀）かなと思ってました。島田は絶対ないですよね、ひょろがりの探偵が主役みたいなもんですから（島田壮司先生作品には御手洗というひょろがりの探偵が出てくるので信頼していました）。
ここでずるい話をしますが、実は読む前からヒントをもらっていました。
勧められたときに、今度十角館がドラマになるらしいんだけど、どうやってやるんだろう。小説だから同一人物だってわからないのに。と教えてもらっていました。

なので、角島の大学生の誰かはモリスなんだろうなとモリスが事件解決にノリノリじゃなくなったあたりから確信しました。

なんやかんやでヴァンが犯人でしたが、ヴァンが犯人だってわかるシーンは爽快でしたね。君も何かあだ名があるのかい？からの発表、しかも文庫本で次のページにめくった時に判明。爽快です。

以上が感想のだいたいです。後はちょっと細かい気になったところを書きます。

・エラリイの全然的外れな推理が悲しくなった。もう少し賢いやつ、なんだったら島でエラリイが解決してくれるのかと思ったけど、解決してくれなくて悲しかった

・エラリイの手品が何かトリックに生きてくるかなぁと思ったけど、あれはブラフでしたね。どこにトリックのヒントがあるかわかりません、馬鹿なので

・エラリイが地下で転んでけがしたの、あれ一応仕掛けてたのかってなりましたw　エラリイが馬鹿すぎて勝手にこけただけで、なんでこいつ被害者ずらしてるんだって思いました（一応糸はあったようですが）

・アガサ、絶対かわいいよね

・結構最初の方にコナンが手紙受け取った人に電話した時に、東一というルルウの本名を聞くことになります。この東一が本名だという要素はどこかで使うかな、とメモっていたのですが、新聞に載るまで不要でしたね。これもブラフでした

・アガサとオルツィが十角館で働かされていて、今のTwitterにいるようなお局様が読んだら綾辻先生叩かれるんじゃないかって思いました、たばことかもみんなめっちゃ吸ってるしね。かっこいいぜ（吸わない）

以上です。

十角館を読んだ人には、綾辻先生の他の作品を勧めたいのですが、あいにくAnotherしか知らず。Anotherは読んでください。

私がこのような思考の原因となった島田壮司先生の本を紹介させてください。あまり聞いたことが無いかもしれないですが、十角館のあとがきに名前があがるくらいには有名ですし、期待を裏切らない作品だと思います。

斜め屋敷の犯罪 (講談社文庫) | 島田荘司 |本 | 通販 | Amazon

また、皆さんのおすすめの小説を教えてください。推理小説に限る必要はありません。

ここまで読んでくださりありがとうございます。

でかすぎるおっぱいは身を滅ぼす。

2024-05-04

読んだ本

前書き
感想
学んだこと

前書き

GWに読んだ本、せっかく読んだので忘れないようにBlogにまとめようと思った。

読んだ本：現場で役立つシステム設計の原則

著者：増田　亨

https://www.amazon.co.jp/%E7%8F%BE%E5%A0%B4%E3%81%A7%E5%BD%B9%E7%AB%8B%E3%81%A4%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E8%A8%AD%E8%A8%88%E3%81%AE%E5%8E%9F%E5%89%87-%E5%A4%89%E6%9B%B4%E3%82%92%E6%A5%BD%E3%81%A7%E5%AE%89%E5%85%A8%E3%81%AB%E3%81%99%E3%82%8B%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%81%AE%E5%AE%9F%E8%B7%B5%E6%8A%80%E6%B3%95-%E5%A2%97%E7%94%B0-%E4%BA%A8/dp/477419087X/ref=sr_1_1?adgrpid=119676456950&dib=eyJ2IjoiMSJ9.sf0dx8kUfM4vNq5sWnkHIk28_qYlN6sTjHZE0xSUbwGq1yu2X9euuKgnk3Np9aDJH2NbOOHGpjySXGL6HoXRlRe3s7owcTo3HuS4X3En4Q6CtCQMJDJkpyjOtUx57_DK679mfOJ4YjxvhtsWvl2uOHqXxB9te36SsIKRR3VMBuXCwOhDpKA75RtD5veVTsDy6IQedcmHGUGk1x_lDajHJpc-BJmH-pCyZ-yQh__rGUo.a66PleYz9GTtkXterPTQuawzNidcOgPvycsi_6H6zjI&dib_tag=se&hvadid=678980112366&hvdev=c&hvqmt=e&hvtargid=kwd-330189736777&hydadcr=27268_14738204&jp-ad-ap=0&keywords=%E7%8F%BE%E5%A0%B4%E3%81%A7%E5%BD%B9%E7%AB%8B%E3%81%A4%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E8%A8%AD%E8%A8%88%E3%81%AE%E5%8E%9F%E5%89%87&qid=1714815384&sr=8-1

感想

今まで自分が4年間開発してきたシステムはオブジェクト指向の顔をした手続き型だったんだなと思った。簡易ドメイン駆動モデル（DDD）だとは聞かされていたが、オブジェクト指向からは離れた手続き型であることを思い知らされてむなしくなった。

これを機に、とりあえずオブジェクト指向の扉を開きたいと思った。

この本はオブジェクト指向というかなり広い概念について網羅的にかかれている。GWの前半にDDDの本を読んだけどそれよりはすぐに実践するというより、こういう考えをもって開発しよう、プロジェクトを始めようといったニュアンスが強いかも

学んだこと

とにかくドメインモデル（エンティティ）にはフィールドだけでなく、ロジックも束ねてまとめる。ドメインモデルをデータとロジックのセットで考える
ドメインサービスといった楽なサービスを頼らず、なるべくドメインモデル内に書くことを心掛ける
三層アーキはドメインモデルを含めた三層アーキ＋ドメインモデルを基本構成とする。
repositoryはDBに依存せずにドメイン毎に作る。DDDっぽい書き方だと、repositoryとその実装クラスのdatasourceはドメイン毎にクラスを切って、datasource内のDBアクセスを実際のDBに即したDBに登録する感じにする
例えば、注文と注文の詳細情報の2つを管理するテーブルに対して、注文登録というユースケースを実現する場合、注文テーブル・注文詳細テーブルそれぞれに対してrepositoryを切るのではなく、repositoryはあくまで注文クラス1つだけにし、その実装クラスであるdatasourceで2つのテーブル（注文・注文詳細）に対してinsertするようなロジックを記載する

以上の3つが学び。

以降では、それぞれの章で学んだことを記載する

第一章：小さくまとめてわかりやすくする

変更が大変なプログラムの特徴

メソッドが長い
クラスが大きい
引数が多い

変更が楽になるプログラムの書き方

わかりやすい名前を使う
量をaやb、q、qtyと書かずにquantityとかく
長い処理をまとめる、空行を使う。切る
目的ごとに変数を使う
メソッドに切る
重複した処理をなくす
狭い関心毎に特化したクラスを作る

基本データ型を使わずに、値オブジェクトを作る

値オブジェクトとは、フィールドを1つや2つだけ持った小さなクラス。そこに基本データ型だけではチェックできないことをチェックする。
例えば、郵便番号をただのstringにするのではなく、郵便番号クラスを作ってハイフンの前後で別のフィールドを定義するよな感じ。

⇒ただ個人的な感想では、Spring的にはBeanValidationを使えば値オブジェクトはいらないかなぁという感想。何か不具合のあるデータはだいたい登録系でBeanValidationつけれると思うから

ファーストコレクションにする。ファーストコレクションとはリストやコレクションを使わずに、リストを1つだけフィールドにもったクラスを作る。リストへの操作は全てこのクラスを介して行うようにする。そうすることでリストへの変更操作をクラス内に閉じ込める

第二章：場合分けのロジックを整理する

ifの処理をメソッド化する

elseを使わない。ガード節、早期リターンをする

条件に従ってインスタンスを変化させたい場合はIFを使う（多態）

enumを使って状態遷移を明確にする

第三章：業務ロジックを分かりやすく整理する（大事）

データクラスの色々な呼び方

DTO・・・サブシステム間でデータをやりとりするための設計パターン
Entity・・・DBとデータをやりとりするためのデータの入れ物
Form・・・画面とデータをやりといするためのデータの入れ物
JavaBean・・・開発ツールやフレームワークを意図して制定された共通のデータアクセス仕様に準拠したクラス

業務ロジックを重複させないための設計

メソッドをロジックの置き場所にする
ロジックをデータを持つクラスに移動する
使う側のクラスにロジックを書き始めたら設計を見直す
メソッドを短くしてロジックの移動をやりやすくする
メソッドでは必ずインスタンス変数を使う
クラスが肥大化したら小さく分ける
パッケージを使ってクラスを整理する

三層アーキ＋ドメインモデル

プレゼンテーション層・・・UIなど外部との入出力を受け持つ
アプリケーション層・・・業務機能のマクロな手順の記述
データソース層・・・データベースとの入出力を受け持つ
ドメインモデル・・・業務データと関連する業務ロジックを表現したドメインオブジェクトの集合

第四章：ドメインモデルの考え方で設計する

特になし

第五章：アプリケーション機能を組み立てる

SpringFrameworkですぐ実現可能。

サービスクラスの設計はごちゃりやすい

ドメインオブジェクトが業務ロジックの置き場所として十分機能していない
プレゼンテーション層の関心毎に振り回される
DBの入出力の都合に引きずられる

ユースケースの複合系は小さなAPサービスとそれを活用する大きなAPサービスに分ける⇒ただトランザクションがちょい気になる

第六章：データベースの設計とドメインオブジェクト

オブジェクトとテーブルは別物

UPDATEをしない！？

第七章：画面とドメインオブジェクトの設計を連動させる

タスクベースのユーザインタフェース・・・Amazonの商品購入までのプロセスのようなもの。商品購入までには①購入者の情報入力②商品の登録③決済方法の登録④配達手段の登録　など複数プロセスにわたって必要事項を入力しなければならないが、そのすべては同時に行う必要はなく、事前に1つ1つ行っておくことが出来る。用途に特化した小さな部品に分解すること

画面表示項目用の数字のカンマ区切りやフロントエラーメッセージ、cssのプロパティなんかも業務ロジックが入っているんならバックで返却すべきという考え

⇒これはさすがに面倒だと思う。

第八章：アプリケーション間の連携

アプリケーション間の連携方式

ファイル転送
DB共有
WebAPI
メッセージング（非同期通信・ソケットAP？）

使いにくいWebAPI

データを取得するために指定するパラメータが多い
取得したデータの項目数が多い
登録時に指定しなければいけないデータ項目が多い

REST Controller

SwaggerUI

複雑なWebAPI

コアとなる基本API・・・どの利用者にも共通するAPI
拡張API・・・利用者がより使いやすいようにコアを集めた複合API
個別対応API・・・個社API

第九章：オブジェクト指向の開発プロセス

書かれていること：ウォーターフォールではオブジェクト指向無理や、アジャイルやろう。どんだけ手の込んだ設計書作っても開発者が設計者と違うのならいいものができるわけないし、後工程の変更でどうするの？設計と開発は一緒にやろ

第十章：オブジェクト指向設計の学び方と教え方

書かれていること：オブジェクト指向の効力を感じれるのはリリース後の改善活動をしているとき。まずは今作っているコードを改善しよう

リファクタリングの対象。リファクタリングは少しずつ始めよう

重複したコード
長いメソッド
巨大なクラス

いい本

「リファクタリング　既存のコードを安全に改善する」　著Marthin Fowler
「ThoughtWorksアンソロジー　アファイルとオブジェクト指向によるソフトウェアイノベーション」　著ThoughtWorks
「実装パターン」　著Kent Beck
「オブジェクト指向入門」　著Bertrand Meyer
「エリックエバンスのドメイン駆動設計」　著Eric Evans