にじさんじの話がしたい 最強雀士決定戦

2020/4/18の夜、にじさんじの麻雀大会の決勝戦があった。

youtu.be

こんな最後まで劇的な麻雀ある！？
予選から決勝に至るまで見どころだらけすごい大会であった……。

僕的にはグウェルが一番注目しているライバーだった。
ほんの1ヶ月前まで麻雀初心者だったが勉強、練習配信を積み重ねていた。
もっとも異様に配牌が良かったのもあるが、大まかな点数計算が出来るようになって明らかに上手くなっていることがわかる。
というか見ている限り基本的に「固い」打ち方をしているし性格に出ているのだろう。

それと矛盾するようだが自ら炎上しにいこうとするところがある。
本人も「ヒール」といっていたが確かにプロレス的なギミックがあることで面白いことはある。
ただ実際1ヶ月前頃にarkの件で普通に炎上していた。
あんまりこういう謝罪動画は好きではないのでちゃんと見てはないのだが「二度とコラボしないでほしい」など辛辣なコメントが多々あった。
炎上自体は数日で収まってたがV界隈はゲームでちょっと空気読めない行動しただけで何故こんな炎上してしまうんだという気持ちがある。

正直麻雀でも下手したら炎上してしまうのではないかとビビっていた。
実際決勝も終盤まで神配牌で高得点で、このまま終わってしまったら他ライバーの反感を買ってしまうのではないだろうか……？
もっともこればかりは自分ではどうしようもところではあるので、言われたとしたら完全に言いがかりなのだが。
しかし最後最後の逆転劇が起こる。さながらラスボスのグウェルは剣持にまくられ、僅差で2位になったのであった。

試合終了後のインタビューでも舞元啓介が4人それぞれの麻雀に対して「良い麻雀だった！」と褒め称えていた。
さながら感動のラスト。ただこれも実況や司会での盛り上げがあってこそだし、さすが舞元だと思う。
下手したらクソプレイだと叩かれかねない事件も多々あったのにも関わらず、舞元のツッコミでめちゃくちゃ笑ってしまった。
野良猫の回での口上は本当にすごい。
「今、熱いバトルが展開しようとした最中！すべてを終わらせたのは！15分遅刻したにじさんじ二期生！にじさんじが誇るパンドラの箱！野良猫こと文野環だ！最下位！」
ここは何度聞いても笑ってしまう。

ただゲーム上級者ではなく初心者がめちゃくちゃなプレイをするのが許される、というか人気なのがにじさんじのゲーム実況なんだろうと思う。
友人と話すと普通に上手い人のゲーム実況が見たいという人が多い印象なのだが、僕的には下手な人のほうが親近感があって良い。
もちろんにじさんじの中にはゲームが上手い人もいてそれはそれで面白いし解説などもあってそこが絡む良さもあるのだが。
バラエティ番組とかでタレントがわちゃわちゃしているのに近い面白さがあるのだと思う。

今回の麻雀大会を見て自分ももっと麻雀やってみようかなとなったし、麻雀ってこんな面白くなるんだなと思えた良い配信であった。

prime readingで読んでなかった有名な本を読む

学生の頃にamazonのプライム会員に入ってから惰性でずっと入っている。
特典の一つとして一部の本が無料で読めるprime readingというサービスがある。
ぶっちゃけ読める本は割と限られているわけだが、未読で割と有名どこの本もあったので読んでみた。
本記事中の2冊はどちらも人生を良い感じにするためにはどうすれば良いか、という話を
古今東西の成功者、著名人のエピソードを交えてストーリー仕立てで解説している書籍となる。
どちらも平易で読みやすく役に立つ本だと思うのでおすすめである。

仕事は楽しいかね？

仕事は楽しいかね？ (きこ書房)

とにかく小さなチャレンジを繰り返すことが大事という話をしている。
未来というのは予測不可能なものなので、大きな目標を掲げてそれに向かっていくのは難しい。
小さなチャレンジは経験になるし、運が良ければ利益を得られる。言うほど大きなリスクはなく、何より楽しい。
このような博打であればたくさんやっていった方が最終的には良いポジションにいれる。

色々挑戦してみようみたいな話は割と世間一般で言われてることだし、自分は元々色々手を出す方の人間だと思っているのだが、
この書籍はもっと小規模な賭けをそれこそ毎日やろうという。流れに身を任せる、とも言える。
仕事にしても「とりあえずこのスタイルでしばらく様子見るか」というより「次は試しにこれやってみるか」ぐらいのスタンスに寄せている。
結果としてはこちらの方がより変化を楽しめるし、以前よりスキルが上がったような感覚はある。
ただ長期の目標とかは仕事の都合上建てざるを得ない場合があるので、それはそれで検討したりはしている。

夢をかなえるゾウ

夢をかなえるゾウ

色々なアドバイスをしているが大雑把に言えば周りに感謝しようという話をしている。
これは人もそうだが物や神仏に対しても、である。根拠が無いといえばそれまでだが、
普段から周りに感謝する生活をすることで自然とそのような振る舞いができるようになり自分と他者の関係性が良くなっていく。

この書籍にあったアドバイスを全部実行したわけじゃないが、
著名人の過去のエピソードや引用があると信頼度が高まるし、元々の自分の思想に近いこともあって実践してみたいという気持ちになった。
というところでレストランの店員さんに優しくするとか、友達や会社の人と関わるときちょっと気をつかうとか、
自然に出来るようになってきて習慣づいてきていると思う。

「小さな挑戦を沢山する」「周りに感謝する」はどちらも意識高い、綺麗事に見えるし即効性は無いのだが
ほとんどデメリットが無く長期的に見て効果がありそうな習慣なので続けたいなと思う。

3年目になっちゃった

過去の様子

入社直後の様子（今見るとキツイ）
woody-kawagoe.hatenadiary.jp

1年経過の様子
woody-kawagoe.hatenadiary.jp

現在

新卒入社から2年経過した。
そろそろ新卒だから仕方ないねですまない領域に入ってしまった。（前からそう）
Twitterを見ると近い年代の人々はリードエンジニアとかSREとかなんか超有能感を出していている。（前からそう）
一方その頃俺君は……。

会社では一応3つのプロダクトを扱うチームのメンバーなのだが、実質1つのプロダクトのもろもろ全部をやるリードエンジニアと化しつつある。（ただしあくまでメンバー）
他チームの人々と調整して、設計、実装、テスト、リリース、問い合わせ対応、障害対応とか大体全部やっている。
とはいえ上司のサポートはゼロではないし、外部でアピール出来るような突出したスキルはあるわけでもなく、まんべんなく地味に仕事をしている。
評価は高くなってほしいが責任が重くなるのはイヤ、という気持ちがあるのだが、現実は責任が徐々に重くなっているだけで評価は大して変わってない。
もっとも今考えるとアピール能力があまり無いのと外部への露出が少ないのが原因かなというのはある。

技術のスキルはどうなったか？
というと最近は技術への興味がだいぶ失われていて、課題解決に必要でないものはどうでもいいという価値観になっている。
強いて言えばGCPへの興味はあるが、仕事で必要な部分だけやろうかなという程度。
この辺はキャッチアップして利用するのにそんなに時間がかからなくなってきている。
これ自体は良いことかもしれないが、それだけに軽視するようになってきた。
一方業務外では基本vtuber追ってるかジム行ってるかというところで技術研鑽はほとんど出来てない。
どちらかというとソフトスキル、ビジネススキルに注目が行っている。
別にPMではないのだが一人プロジェクトが増えたことを顧みて、PM関連について学んでいる最中。

仕事関係ないところでいうと大きな変化として彼女が出来た。
これにより精神的な負荷が大分無くなり、婚活にさくリソースを別の所にまわせるようになった。
実際ジム行く頻度が増えてちょっとだけ痩せた。
ただ昨今のコロナの影響でジムがほぼ閉鎖状態になりいけなくなってしまったので家で鍛えるしかない。

今後

書籍「SOFT SKILLS」を見習ってアウトプットを増やしたいなと思っている。
ちょうど技術記事書くぞというときにQiitaがやらかしたのでちょっと控えたが、
結局日本語で技術記事となるとQiitaというのはまだ変わらなそうだししばらくしたら投稿しようかなと思っている。
アウトプットが多くて社交性があると間違いなく有能感が出て評価も上がっていくはずなのだが、
謎プライドがあるのでクソ記事は控えたいし人脈も広げたくない、言うたら面倒なのでうだつの上がらない生活を送っている。

ただ自分や人の仕事を楽にして行きたいという思いはずっと変わっておらず、
そのためにスキルを伸ばしたいという気持ちはあるのでアウトプットや社交はある程度していきたい。

京都オタク五人旅

高専のオタクと5人で旅行に行ってきた。
もとはと言えば「響け！ユーフォニアム」の上映会に呼ばれて見て、
その流れで聖地になっている宇治に行こうという話になったのであった。

10/25

早目に仕事を終えて新幹線に乗る。
普通なら皆一緒に移動、泊まりだろうからまとめて予約するもんだろうと思っていたのだが、
この時点でもう意思がバラバラで「俺は飛行機で行く」「サウナ行きたい」「前乗りする必要ないからいいや」などの自由さであった。
実際行きの新幹線は2人で行って、京都着いてからは別々のところに泊まった。

初めてカプセルホテルに泊まったのだが4kしないくらいの値段で、
でかい風呂、漫画読み放題、朝飯バイキング有り、ホテルスタッフの干渉がないと最高の環境であった。
実質ミニマリストなのでベッドも特に不満無し。
これからは一人旅行ならカプセルホテルにしようと思った。

10/26

昼頃京都駅近くに五人のオタクが集合した。
宇治駅まで移動し、そこからレンタカーで移動。
聖地であるアクトパル宇治、モデルになった高校とかサイゼ、天ヶ瀬ダムなどを見て回った。
（高校は流石に入れないので脇道通るだけ）
こんなシーンあったなぁ、と思い返しつつ、単純に自然崇拝したりダムすげーとか観光していた。

夜はゲストハウスに泊まった。
このタイプの宿泊施設も初めてだった。
本当に家と中にアメニティがあるだけで、スタッフはおらず無人である。
でかい風呂があるので5人で入ったり、お互い腹が出てきていることにビビって、腹囲順に並んで写真撮ったりした。

夜飲みに行って帰ってくるころには疲れ果てていてかなり早く寝たのだが、
途中部屋の外から人の声がして目が覚めてしまった。
ゲストハウスに誰か侵入したのか！？と思ってかなりビビったのだがそのまま寝た。
起きてから分かったのだが、僕のイビキがうるさすぎて部屋の外で寝てたオタクのイビキであった。
本当に申し訳ないと思っている。

10/27

引き続き宇治周辺を観光したり一通り「響け！」の聖地を見終えた。
僕としては森見登美彦の作品（四畳半神話大系とか夜は短し歩けよ乙女とか）が好きなので下鴨神社や鴨川デルタ付近を見て回った。
また近くにたまこまーけっとの舞台になった商店街もあったのでそこも覗いたりした。
今回僕は下調べとかなんにもしていなかった。
「有田と週間プロレス」で有田が「単純に（プロレスを）見るのも面白いけど、背景知識があるとより楽しめる」という話をしていた。
もっと文脈を分かっていればより楽しめたかもしれないと少し後悔しつつ、適当に見に行くだけでも気楽に楽しめたなという安定の怠惰さもあった。

夜は旅館に泊まった。外で飲んでから泊まったのだが、
昔であれば旅館の部屋の中で飲んでダラダラしてただろうに、そういうのは一切無く、
風呂入ったあとはすぐに寝た。
観光中も疲れて喫茶店によることが多くなり、健康状態が話題になったり（腹は前から気にしてはいた）、
無理したところで別に面白くないしなと思って深酒や徹夜も無くなった。
これが年なのであろうか。
こうしたいからこうしてるだけなので良いことではあるはずなのだが、
少しさびしい気もする。

なおこの日もイビキがひどかったらしく証拠動画が撮られていた。
さらには途中で演奏終了（？）してたようで無呼吸症候群の危険性が高くなってきた。
一人暮らしだとイビキの異常に気づけ無いし、友達と旅行に行くのは良いことずくめということである。

10/28

近場で土産を買ったり、神社仏閣を見て回った。
途中、安井金比羅宮によったのだが、なんと悪縁を切ってくれることで有名らしい。
ちょうどここ最近出会い系で人脈大好き人間や副業推す人間ばかりと遭遇して精神崩壊太郎と化していた僕にはうってつけであった。
これで悪縁が切れることを祈る。
その後はまた別行動で一人でブラブラ歩いていたり、また合流してにぼ次郎のラーメンを食ったりしていた。
またチルアウトしたのち都内に戻るのであった。

まとめ

• 痩せよう
  • 飯はゆっくり食べよう
  • 聖地いきまくれば楽しく運動して痩せれるはず
  • 痩せればイビキ対策になるはず
• 協調性無いので一人行動楽しい、主体性無いので団体行動楽しい
  • 一人ならカプセルホテル最高
  • 複数人なら一日中温泉旅館でダラダラもあり
  • 次は佐渡とか月岡温泉とか？

「現場で役立つシステム設計の原則」を読んでます（8-10章）

8章 アプリケーション間の連携

アプリ間の連携の方法について、特にREST APIの話が中心に解説している。
URIはリソースと一致させる、ステータスコードやHTTPメソッドが正しく対応しているかなど、
規約に沿うことで分かりやすく利用しやすいAPIとなる。

Web API: The Good Parts

またJSONよりもXMLのほうがメタデータを使えるし複雑なデータを再現するならXMLのほうが良いと主張している。
これに関してはあんまり賛同していなくて、そんなメタデータ渡す必要あるのだろうか、
JSONで簡潔に済ませたほうがいいんじゃないかと思った。
これこそアプリによる課題かもしれないが。

またメッセンジャーを利用することで、疎結合な非同期通信を行えるので良しとしている。
具体的なサービス名について明記してなかったが、GCPのPub/Subがこれに相当すると思う。
たしかにアプリ間で直接やりとりするのではなく、Pub/Sub経由を前提とすることで、
疎結合になりアプリ単体のテストがしやすくなる。

複数の小さなサービス間の連携を行う設計、マイクロサービスについても触れている。
このようにサービスを分割して検証しやすくするのはオブジェクト指向の考え方にも沿っている。
ただマイクロサービスだと一部分割したサービスを統合したり移譲したりするのが難しい。
そのため深いドメイン知識が必要とされる。
以下の書籍でも初めは単一のアプリ（=モノリス）から実装し、ドメインについて詳しくなってから徐々に分解していくことを是としている。

マイクロサービスアーキテクチャ

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

今までメジャーだったウォーターフォールは、設計、実装、テストを別々の人で分業して行っていた。
一方最近流行りのアジャイルは、このサイクルを1,2週間のスプリントとすることでより速いサービスの改善を試みているが、
実装に寄りがちで設計、テストがないがしろになりがちである。
結局、ドメインに詳しい人間が設計、実装、テストのすべてを担当することでブレ無いドメインモデルが出来る。
また無駄にドキュメントを作ることはせず、コードこそが全ての仕様書となるようにする。

この辺の主張はまぁ分かるのだが超優秀な人間を前提としているような気がした。
実際自分もこれに似たようなことはしているのだが、コードから全てを把握するのはまだまだ出来ないし、
設計も実装もテストもまだまだスキル不足を感じる。
分かりやすいようにドキュメントがほしいと感じるのだが、書いてもすぐに陳腐化するし、そもそも誰も読んでくれないし、
結局頑張ってコード読むしか道は無いような気はしている。
コードを理解するスピードがあれば済むということであればOSSのコードを読み漁るとかすべきなのだろうか。

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

「どうすればオブジェクト指向設計を理解出来るのか？」「体で覚えよ！」
以上、という感じの章である。
こう書くと脳筋感があるが、いくつかのルールに乗っとってコードを書くトレーニングをすることで身につく、という話である。
たしかに動物をクラスとして鳴き声がメソッドで〜みたいな例を出されても結局何が嬉しいのか謎である。
ならば実際に実装してみてオブジェクト指向の良さを体験すれば良い。
紹介されているルールは基本的にlintでチェックされるようなものも多いが、例えば「全てのプリミティブ型、文字列型をラップする」というものがある。
手続き型の書き方だと難しいルールだが、このようにオブジェクトを多用することで結果としてオブジェクト指向の書き方になるという寸法である。
またいくつかオススメの書籍についても解説しているが、一番は「エリック・エヴァンスのドメイン駆動設計」のようだ。

ふりかえり

そうだよなー確かになー本当かなーとか色々思うところはあったが、全体的に平易で読みやすい書籍だった。
勝手に初級者向けのDDD本と思って読んでたが（まぁ実際そうだったが）
値オブジェクトとリポジトリ以外のパターンについてはほとんど記述がなかったように思う。
エンティティとか（極力使うなという話？）ファクトリとか（チラッと出てたけど）
そういうパターンとか考えないでひとまずオブジェクト指向に慣れろという話かもしれない。
とはいえ層とかパターンみたいなものをちゃんと理解しない開発についてけない感はあるので、
そろそろ原本を読んで勉強しようかなというところ。
あとは書籍じゃなくて開発するとかコードリーディングするとか実践経験を積むしかなさそうな感じはする。
以上です。

前々回
woody-kawagoe.hatenadiary.jp

前回
woody-kawagoe.hatenadiary.jp

「現場で役立つシステム設計の原則」を読んでます（4-7章）

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

まずドメインモデルはデータモデルとは異なりロジックがあると述べている。
よくあるパターンとしてデータはクラスか変数として、ロジックは関数として別々に作ってしまう。
もしくはフレームワークに合わせて適当にクラスを作成するとか。
しかしオブジェクト指向ではデータとロジックはまとめ、オブジェクトとして扱うものである。
これにより業務データとそれに関連する処理を一元化することができ、シンプルな構成になる。

またトップダウンでなくボトムアップの設計を推奨している。
一個一個の部品=ドメインオブジェクトを作り込む。
とはいえどのような部品が必要になるかは知る必要があるので業務フロー図やパッケージ図を用いておおまかな地図を書くことから始まる。
（これだけ見ると結局トップダウンじゃんという感じはするが）
結局のところ全体と部分を行ったり来たりしていくことが大事ということである。

開発を進めることで徐々にドメイン知識が身につくはずである。
そのため徐々にドメインモデルを正確なものに改善していくことができる。
「リファクタリング」でもクラスの分離や結合、移譲などの話をしているが、
これもオブジェクトの構成を改善するための手法の一つである。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

またドメインに関する語彙とドメインモデル中の変数名や関数名を一致させることでより分かりやすくなる。
ドメイン知識が少ないうちはまずは専門用語を身に着けていくと設計がしやすくなる。

データとロジックを合わせて設計をするというのはまだなれないところだが、
これが出来るとシンプルな実装に出来るかと思うので実践してみようと思う。

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

アプリケーション層のクラス=サービスクラスは複雑になりがちであるが、業務ロジックはドメイン層に書くべきである。
MVCでもfat controllerを避けるべきみたいな話があるが同様のことだと思う。
（ググったら機関車トーマスに出てくる局長のキャラクターもfat controllerと呼ばれてるらしい）
業務ロジックは出来るだけ細かくし、サービスクラスはその組み合わせを構成する。
プレゼンテーション層では入力を受け、サービスを呼び出して適用し、出力を返すだけで、ここにロジックは置いてはいけない。

またサービスクラスからデータベースの都合を切り離すために記録と参照のみを行うクラスとしてリポジトリを利用する。
具体的なデータベース操作はリポジトリ内に記述することで、サービスクラス内では記録と参照を行っているということだけがわかるようにする。

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

データベース設計では制約を行うことでプログラムの記述を簡単にする。
具体的にはNOT NULL制約, 一意性制約、外部キー制約である。
この辺は「データベース実践入門」にも記載があった。
（この書籍だともっと厳しい正規形についても述べている。）

理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

特に一意性制約は重視したい。テーブル内のカラムでどれが一意になる組み合わせを考え、
それを複合キーとして設定することで参照が楽になる。
個人的に最近はNoSQL(datastore)を利用する機会が多い。
そのため外部キーを利用してJOINでつなげることが少なく、使用場面を考慮したテーブル設計になっていることが多い。
それでもNOT NULL制約、一意性制約に関してはNoSQLのテーブル設計にも役立つ。

またオブジェクトとテーブルの設計は異なる点に注意すべきである。
オブジェクトはロジックを含むがテーブルはデータのみを管理する。
フレームワークによってはテーブル設計とオブジェクトが一致するような命名規則を強いるものがあるが、
このようなフレームワークは避けるべきとしている。
MVCだとmodelがリポジトリ兼ドメイン層となってしまっている。
「現場で役立つシステム設計の原則」だとJavaのSpring bootがドメイン駆動を再現しやすいとして推奨している。
僕としては制約の少ないシンプルなフレームワークを利用して必要な部分だけ利用すべきかなと思っている。

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

UI中に業務ロジックをおくべきでない。DDD本でもこのようなUIは「利口なUI」としてアンチパターンとしている。
また複雑な画面になってしまう場合は分離すべきである。
たとえばユーザー登録画面でも1画面にすべての項目を入力するのではなく、
いくつかのフローに分離した画面のほうが開発しやすく、ユーザ側としても使いやすい。
またユーザーの関心事に注目して設計すれば画面の内容とドメインオブジェクトが連動してくるはず。
それから画面の設計には近接、整列、対比、反復を重視すべきとしている。
これはノンデザイナーズ・デザインブックに書いてある話である。

ノンデザイナーズ・デザインブック [第4版]

ふりかえり

今まで読んできた本とのつながりが見えてきたのが良かった。
特にDB設計に関して学んできたことは変わってないなと思う。
一方でデータと業務ロジックをオブジェクトとしてまとめるということはまだ出来てないなと感じる。
また今自分が開発に携わっているシステムが、どうして今のような構成なのか、
どうしてこのようにオブジェクトを分けて設計しているのかなど、設計の意図を把握しやすくなったような気がする。

前回
woody-kawagoe.hatenadiary.jp

「現場で役立つシステム設計の原則」を読んでます（1-3章）

DDDやっていきたいなーとか言ってたら同期にこの人の本良いっすよと言われて読んでみたのだが思った以上に良い感じだった

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

1章 小さくまとめてわかりやすくする

ソフトウェアの変更が大変なのはどこをどのように変えればいいのかが分かりにくいのが原因。
だから分かりやすい構成、設計にするべき。
始めの方は「変数の命名はxとかじゃなくて意味がわかるものにしようね」とか、
「DRY原則を守る」とかリーダブルコードに書いてあるような基礎的ですぐに実践しやすいことが記載されている。

ここで数値だったらなんでもbuildinの型使っちゃダメよと言っている。
例えばお金を示す値だったら整数だからとりあえずint型かなとしがちである。
が、システム内ではintの最大値と同じ金額を使うパターンが無いとか、100円単位で使われる可能性がある。
そのため専用の型として「値オブジェクト」を使い仕様を厳しくするべきである。
これにより異常値が入ってエラーが発生するということを防ぎやすくなる。

エリック・エヴァンスのDDD本とか実践DDD本とかだと割と後の章で値オブジェクトの概念が解説されるので1章目でこの話をするのかーと思った。
でも確かに「〇〇という概念がある。それは〜」という説明よりは「こういう課題があるので対策としてこういう設計がある。これを〇〇という。」という方がストーリーだっていて分かりやすかった。
また、よくエンティティと値オブジェクトの違いは可変か不変かですよという説明は見ていたのだが、なんでそういう分け方にしてるのかとかはよくわかっていなかった。
この書籍だと値オブジェクトの利用例があり分かりやすい。（他の書籍や記事でもあったのかもしれないがたどり着けてなかった）

2章 場合分けのロジックを整理する

基本はif-else文だと入れ子構造が深くなっていて複雑になるから控えようね、という話。
対策として「ガード節を使う」、「カテゴリ用のEnum作っておく」、「多態性（ポリモーフィズム）をもたせる」などがある。
これは書籍にはなかったが個人的には以下のような辞書型を使ったスクリプトで場合分けを行うことが多い。（上司に教えてもらった）

# 元コード
fruit = input()
if fruit == 'apple':
  return 100
else if fruit == 'orrange':
  return 200
else
  return 0

# 改良版
fruit = input()
prices = {'apple': 100, 'orrange': 200}
return prices.get(fruit, 0)

3章 業務ロジックを分かりやすく整理する

書籍ではデータクラスとロジックは分けないで書こうという話をしている。
正直言うと僕は役割が異なるから別で分けるものという認識だった。
しかしここを分けてしまうとデータクラス、ロジックの変更の影響範囲がどこなのかを調査するのが難しくなってしまうという問題がある。
データクラスとロジックをあわせて業務内容を再現したオブジェクトをドメインオブジェクトという。

また三層アーキテクチャについても触れている。ここでいう三層は以下の層を示す。

1. プレゼンテーション層
2. アプリケーション層
3. データソース層

n層とかレイヤーアーキテクチャとかはよく聞くのだが、上記の層含めどういう層があるのかとかはいまいち分かってなかった。
MVCでいうとそれぞれV, C, Mが対応してるんだろうか。
同じような役割の層でも呼称とか変わる場合もあるし難しいものである。flaskとかだとMVTだし
書籍では業務領域を表すドメインオブジェクトの集合であるドメインモデル（ここが一番複雑な処理になるはず）を別の1つのレイヤとして持つことで他の三層の記述は簡潔になる。

ふりかえり

手元に以下のDDD関連の古典がある。まだ全部は読みきれてない。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

実践ドメイン駆動設計

頑張って古典を読んで理解しようと思ってたのだが、その途中で「現場で役立つシステム設計の原則」に触れておもしれーってなったので一通り読み進めたいところ。
これ読み終えたら上記2冊も読んでより理解を深めたい。
割と実装してる最中でも（この実装この階層であってんのか……？）となって開発に手間取ったり手戻りすることがあったりするので、サッと判断して爆速で開発できるようになりたいものである。
引き続き4章以降も読み進めます。