「現場で役立つシステム設計の原則」を読んでます(4-7章)
4章 ドメインモデルの考え方で設計する
まずドメインモデルはデータモデルとは異なりロジックがあると述べている。
よくあるパターンとしてデータはクラスか変数として、ロジックは関数として別々に作ってしまう。
もしくはフレームワークに合わせて適当にクラスを作成するとか。
しかしオブジェクト指向ではデータとロジックはまとめ、オブジェクトとして扱うものである。
これにより業務データとそれに関連する処理を一元化することができ、シンプルな構成になる。
またトップダウンでなくボトムアップの設計を推奨している。
一個一個の部品=ドメインオブジェクトを作り込む。
とはいえどのような部品が必要になるかは知る必要があるので業務フロー図やパッケージ図を用いておおまかな地図を書くことから始まる。
(これだけ見ると結局トップダウンじゃんという感じはするが)
結局のところ全体と部分を行ったり来たりしていくことが大事ということである。
開発を進めることで徐々にドメイン知識が身につくはずである。
そのため徐々にドメインモデルを正確なものに改善していくことができる。
「リファクタリング」でもクラスの分離や結合、移譲などの話をしているが、
これもオブジェクトの構成を改善するための手法の一つである。
新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
- 作者: Martin Fowler,児玉公信,友野晶夫,平澤章,梅澤真史
- 出版社/メーカー: オーム社
- 発売日: 2014/07/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (11件) を見る
またドメインに関する語彙とドメインモデル中の変数名や関数名を一致させることでより分かりやすくなる。
ドメイン知識が少ないうちはまずは専門用語を身に着けていくと設計がしやすくなる。
データとロジックを合わせて設計をするというのはまだなれないところだが、
これが出来るとシンプルな実装に出来るかと思うので実践してみようと思う。
5章 アプリケーション機能を組み立てる
アプリケーション層のクラス=サービスクラスは複雑になりがちであるが、業務ロジックはドメイン層に書くべきである。
MVCでもfat controllerを避けるべきみたいな話があるが同様のことだと思う。
(ググったら機関車トーマスに出てくる局長のキャラクターもfat controllerと呼ばれてるらしい)
業務ロジックは出来るだけ細かくし、サービスクラスはその組み合わせを構成する。
プレゼンテーション層では入力を受け、サービスを呼び出して適用し、出力を返すだけで、ここにロジックは置いてはいけない。
またサービスクラスからデータベースの都合を切り離すために記録と参照のみを行うクラスとしてリポジトリを利用する。
具体的なデータベース操作はリポジトリ内に記述することで、サービスクラス内では記録と参照を行っているということだけがわかるようにする。
6章 データベースの設計とドメインオブジェクト
データベース設計では制約を行うことでプログラムの記述を簡単にする。
具体的にはNOT NULL制約, 一意性制約、外部キー制約である。
この辺は「データベース実践入門」にも記載があった。
(この書籍だともっと厳しい正規形についても述べている。)
理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)
- 作者: 奥野幹也
- 出版社/メーカー: 技術評論社
- 発売日: 2015/03/10
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (20件) を見る
SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)
- 作者: ミック
- 出版社/メーカー: 技術評論社
- 発売日: 2015/04/11
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (7件) を見る
特に一意性制約は重視したい。テーブル内のカラムでどれが一意になる組み合わせを考え、
それを複合キーとして設定することで参照が楽になる。
個人的に最近はNoSQL(datastore)を利用する機会が多い。
そのため外部キーを利用してJOINでつなげることが少なく、使用場面を考慮したテーブル設計になっていることが多い。
それでもNOT NULL制約、一意性制約に関してはNoSQLのテーブル設計にも役立つ。
またオブジェクトとテーブルの設計は異なる点に注意すべきである。
オブジェクトはロジックを含むがテーブルはデータのみを管理する。
フレームワークによってはテーブル設計とオブジェクトが一致するような命名規則を強いるものがあるが、
このようなフレームワークは避けるべきとしている。
MVCだとmodelがリポジトリ兼ドメイン層となってしまっている。
「現場で役立つシステム設計の原則」だとJavaのSpring bootがドメイン駆動を再現しやすいとして推奨している。
僕としては制約の少ないシンプルなフレームワークを利用して必要な部分だけ利用すべきかなと思っている。
7章 画面とドメインオブジェクトの設計を連動させる
UI中に業務ロジックをおくべきでない。DDD本でもこのようなUIは「利口なUI」としてアンチパターンとしている。
また複雑な画面になってしまう場合は分離すべきである。
たとえばユーザー登録画面でも1画面にすべての項目を入力するのではなく、
いくつかのフローに分離した画面のほうが開発しやすく、ユーザ側としても使いやすい。
またユーザーの関心事に注目して設計すれば画面の内容とドメインオブジェクトが連動してくるはず。
それから画面の設計には近接、整列、対比、反復を重視すべきとしている。
これはノンデザイナーズ・デザインブックに書いてある話である。
- 作者: Robin Williams,米谷テツヤ,小原司,吉川典秀
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/06/30
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る
ふりかえり
今まで読んできた本とのつながりが見えてきたのが良かった。
特にDB設計に関して学んできたことは変わってないなと思う。
一方でデータと業務ロジックをオブジェクトとしてまとめるということはまだ出来てないなと感じる。
また今自分が開発に携わっているシステムが、どうして今のような構成なのか、
どうしてこのようにオブジェクトを分けて設計しているのかなど、設計の意図を把握しやすくなったような気がする。
「現場で役立つシステム設計の原則」を読んでます(1-3章)
DDDやっていきたいなーとか言ってたら同期にこの人の本良いっすよと言われて読んでみたのだが思った以上に良い感じだった
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
- 作者: 増田亨
- 出版社/メーカー: 技術評論社
- 発売日: 2017/07/05
- メディア: Kindle版
- この商品を含むブログ (4件) を見る
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章 業務ロジックを分かりやすく整理する
書籍ではデータクラスとロジックは分けないで書こうという話をしている。
正直言うと僕は役割が異なるから別で分けるものという認識だった。
しかしここを分けてしまうとデータクラス、ロジックの変更の影響範囲がどこなのかを調査するのが難しくなってしまうという問題がある。
データクラスとロジックをあわせて業務内容を再現したオブジェクトをドメインオブジェクトという。
また三層アーキテクチャについても触れている。ここでいう三層は以下の層を示す。
- プレゼンテーション層
- アプリケーション層
- データソース層
n層とかレイヤーアーキテクチャとかはよく聞くのだが、上記の層含めどういう層があるのかとかはいまいち分かってなかった。
MVCでいうとそれぞれV, C, Mが対応してるんだろうか。
同じような役割の層でも呼称とか変わる場合もあるし難しいものである。flaskとかだとMVTだし
書籍では業務領域を表すドメインオブジェクトの集合であるドメインモデル(ここが一番複雑な処理になるはず)を別の1つのレイヤとして持つことで他の三層の記述は簡潔になる。
ふりかえり
手元に以下のDDD関連の古典がある。まだ全部は読みきれてない。
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (131件) を見る
- 作者: ヴァーン・ヴァーノン
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/19
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
頑張って古典を読んで理解しようと思ってたのだが、その途中で「現場で役立つシステム設計の原則」に触れておもしれーってなったので一通り読み進めたいところ。
これ読み終えたら上記2冊も読んでより理解を深めたい。
割と実装してる最中でも(この実装この階層であってんのか……?)となって開発に手間取ったり手戻りすることがあったりするので、サッと判断して爆速で開発できるようになりたいものである。
引き続き4章以降も読み進めます。
路上プロレス生で見た
皆さんは路上プロレスをご存知でしょうか。
大体こういう感じのやつです。アマゾンプライムでも「ぶらり路上プロレス」とかやってて面白いので皆見ましょう。
それはともかくとして、たまたまDDTのサイト見てたらこれを見つけたので行ってきた。
東京・グランデュオ蒲田「路上プロレスinグランデュオ蒲田」
DDT ProWrestling
試合開始が18:00からだったので会社の会議終わってからすぐ出発した。
Twitter見る限り屋上からスタートするらしかったので、会場付いてからエレベーターで屋上に移動した。
と思ったのだが途中階で降りた瞬間に怒声が聞こえ、眼の前に樋口和貞がいた。男色ディーノもいた。
こりゃ行くしか無いと思いすぐに降りて観戦を始めた。
#路上プロレス pic.twitter.com/R43oYKTCFu
— ウッディ川越 (@woody_kawagoe) 2019年5月10日
#路上プロレス pic.twitter.com/qtbAOoPdzo
— ウッディ川越 (@woody_kawagoe) 2019年5月10日
各階を移動しながら普通の床に叩きつけたりいろんな技をやっていた。
それに合わせて観客はヤジを飛ばしたり写真撮ったりして追いかけた。
男色ナイトメアや地獄門などのコンプラ的に非常に問題のある男色殺法も見た。
19:00頃に決着がついた。ピッタシ1時間くらいだし、タイムキープが素晴らしい。
というか早めに出発しておいて本当に良かった。
すごい近くでよく知ってるレスラーがいるってだけでも貴重な体験だけども、
普通のデパートの中、大人数でレスラーを追いかけるのが体験としていい。
ヤジ飛ばしたり、ちびっこが参戦したり、試合中にレスラーと記念撮影したり、路上プロレスでしか見れないシーンが沢山ある。
もちろんブック(八百長)というか茶番が沢山あるんだけどそれがこの上なく面白い。
他の団体もこういうのやればいいのになーといつも思う。
どう考えても「路上プロレスやらせてください」と交渉するのは難しいし、
明らかに試合後怒られてるんだろうけど。
それに普通に買い物に来てた人からすればクッソ迷惑なわけで……。
ただこういうバカをするというのがこの上なく楽しい。
35でエンジニア定年になったら地元帰ってイオンで路上プロレスするか……
— ウッディ川越 (@woody_kawagoe) 2019年5月11日
したい。どうすれば出来るんでしょうか。新潟プロレスに所属して交渉すればいいんでしょうか。
レスラーデビューコースあったわ。マジかよ。というか大日本と提携とか色々やってるんすね……。
デパートでやるにしてもリングたてるだろうし、路上プロレスはしてなさそうだけど……。
あと選手プロフィール見たらレルヒ少佐とかアオーレ長井とかいて草。
普通に今はエンジニア職しながら総合のジムでやっていきます。
初めてライブハウスに行った
フェスとかはたまに誘われていってたんだけど小さい箱ってあんまいったことない。
行きてぇなぁ行きてぇなぁとずっと思ってたけどようやく行動に移した。
特別気になるバンドがあるわけでは無い。
ただ下北沢は近いしバンドの街というイメージがあったので、たまたまライブやってるところを探して行った。
結局このイベントに行った。
liveholic.jp
箱はこじんまりしてるんだけどそこそこ人はいた。
客層としては大学生くらいの男性女性がほとんど。
意外におばさんもいた。
雰囲気としては割と落ち着いていて、体揺らしながら音楽楽しむ程度。厄介はいない。
空気だけでいえば学祭のライブとかを思い出したけど、
やっぱちゃんとしてるというか流石にプロ(?)で演奏は上手い。
聞いた中だとまちぶせというバンドが一番良かった。
曲も良かったんだけどMCのマシンガントークが面白くて盛り上がった。
「照明で暑い!なんだこの照明、こんな照明初めて見たぞ!たこ焼き器みたいな形して!たこパ、皆さんたこパやったことありますか?いねえよなぁ陰キャしかいねえんだから!」
とか脊髄で話してた。良かった、ロックは陰キャのものなんだ。
他のバンドは結構MCが短くて「後2曲やったら終わりますー」程度で、曲をしっかりやっていく、硬派タイプが多かった。
あと全体の感想としてステージ上で演奏するの楽しそうだなぁというのもあった。学校とかで演奏してたのが楽しかったのを思い出した。
「滋賀県から来ました、〇〇です」とMCしてたバンドがいて、声に出して読みたい日本語だった。(ナンバガリスペクト)
コピバンでもいいけど、このネガティブで憂鬱な感情を歌詞に出来たらなとも思った。
曲としては電子音、重低音、変拍子とかが好きなんだけどジャンル的にどうなるのか、どこでライブやっているのか、あんましよく分かってない。
結局面倒でトラックメイカーにはならないんだろうな。
それはともかくとして今回みたいにフィールドワークしていくと新たな発見あっていいし、
ただ突っ立って聞いてるのも退屈なわけではなく割と曲を楽しめた。
音圧を感じるのがいい。周りがノッているのが分かるのもいい。
もっとライブに参加していく、バンドTを買っていく活動やっていきたい、楽しいので。
Vim再履修
色々あったので一日vimrcいじるなど開発環境の見直しをした。
技術的な話なのでQiitaに書いても良かったけど個人的なvimrcをちょっと改良した、勉強した程度なのでこっちにした。
dotfile
これが今の最高状態や。(更新したらまた変わるわけだけども。)
昔「最強のvimrc晒す」みたいな奴適当にパクって使ってたんだけども、
今回はちゃんと中身理解しようと思って色々調べてから必要な奴だけにした。
dein パッケージ管理
neobundleは死んだ、もういない。(開発中止している。)
ということでパッケージ管理は全部deinで出来るようにした。
調べてる限りだとtomlファイルで別に管理している人が多いようだったけども、
そんなに多くのパッケージ使わないだろうし、管理するファイルを離散させたくなかったのでvimrcにベタ書きすることにした。
利用パッケージ
入力途中で単語のサジェストをする。
日本語ドキュメント。:helpで呼び出せる。
ファイル一覧とか呼べる奴。Ctrl + nで開いたり閉じたり出来るようにした。
map <C-n> :NERDTreeToggle<CR> let g:NERDTreeShowHidden = 1 let g:NERDTreeNodeDelimiter = "😀=" let g:NERDTreeDirArrows = 1 let g:NERDTreeDirArrowExpandable = '▸' let g:NERDTreeDirArrowCollapsible = '▾' let g:NERDTreeGlyphReadOnly = "RO"
いろんな言語のカラースキーマとか勝手にやってくれる君
文法チェッカー君。
synatsticは死んだ。
そんなに細かく設定しなくてもコード書いてる途中に勝手にlinterが動いてくれる。
Ctrl + fでlintに沿うよう修正できるようにした。
flake8, autopep8とかは別でインストールする必要あり。
map <C-f> :ALEFix<CR> let b:ale_linters = ['flake8'] let b:ale_fixers = ['autopep8', 'isort', 'yapf']
インデントの色つける君。
いつもHTMLのタグ間がわからなくなってたのでスペース2個のインデントでも色が変わるようにしてる。
let g:indent_guides_enable_on_vim_startup = 1 set ts=2 sw=2 et
所感
よくわからんまま使ってるところが分かってスッキリしたし面白かった。(小並感)
自称vimmerの割に有名どこのパッケージ使いこなせてなかったのは普通に恥ずかしい。
ただ設定できる範囲がデカすぎるし一日で知るのは到底無理だと思う。
また今度復習とかして見直したいところ。
最近の仕事
新卒二年目に突入した。
エンジニア業もなんやかんやクビにならずに済んでる。
最近疑問なのが近い職種の人とやってることが近いのか遠いのかである。
自分では割と幅広いような気がするのだが、本当に普通より範囲が広いのか狭いのかわからない。
もしかしたら今後ポートフォリオとかに書けるかもしれないのでまとめてみる。
本業
副業
補遺
バイト時代は実装だけとかだったので大分やれることは増えた感。
出来るようにしたいことは色々あるけど、今は仕様の理解・提案をもっと早く精度高くやりたいなというお気持ち。
以上です。
技術書展6に行った
入場
話題の技術書展に行った。
昼間の時間帯が有料だったので14時くらいに会場に行った。
ちょっと眺める程度でいいかなーくらいの気持ちだったので遅めに行ったのだけど、その時間でも結構な列が出来ていた。
ぶっちゃけそれ見て帰ろうかなとなったけどせっかく来たんだと思って並んでいた。
思ったより進みは早くてすぐ会場に入れた。
場内
エンジニアだな〜って感じの人が沢山いて安心した。アキバらへんとか高専の学祭と同様の雰囲気。
同人誌即売会自体行くのが初めてだったけど、アプリ使ってQR読むだけで完結する会計は楽でスムーズだった。
スムーズすぎて買いすぎたというのはある。僕としては投げ銭的な意味合いもあったけど。
混んでるとこは人の流れがかちあっていてちょっと大変だった。
一方向に案内してもいいんじゃ、と思ったけどそう上手くはいかないものだろうか?
混雑時の人の流れいい感じにする手法とかって確立されているんだろうか……
実はあれが最適解なのだろうか……
とはいえずっと身動き出来ないわけではなくて全体はザッと見れた。
技術書
僕が今興味あるのはGCP、設計、フロントエンド周りなど、Web系で自分に足りないかなと思ってる技術だ。
ただフロントエンド周りの技術のが多かったような気がする。タイトルがそれと分かりやすかったというのはある。
あとweb系のバズワード?(PWA, SSR, GraphQL, gRPCとか)の認識がガバガバだったのでその辺も買った。
あと企業が出してる書籍は体裁が整っていて様々なコラムが載ってるのでどれも面白そうな印象があった。
売り子さんと話すのも結構良かった。
GAEの本を試し読みさせてもらったとき、あとがきに公式ドキュメントの愚痴があって分かる〜みたいな話をした。
ぶっちゃけ内容は知ってるやつだったのに買ってしまった。
はたまた全然興味の無いJSのフレームワークの本を手にとったら色々そのフレームワークの良さみたいのプレゼンされてすげ〜ってなったので買ってしまった。
買った奴の一部 pic.twitter.com/bLK5s4FTwe
— ウッディ川越 (@woody_kawagoe) 2019年4月14日
帰ってから技術書展での出費計算したら¥15,500だった
— ウッディ川越 (@woody_kawagoe) 2019年4月14日
乙〜
所感
そういえば僕の夢というか野望の一つとして「書籍を出す」というのがあるんだけど、
だったらこういうとこで本出すところからやりゃいいじゃんと我に返った。
最近読んでる本とかでもアウトプットしていくべきという話は多かった。
理由として自分の理解を深めるのにつながるというのもあるのだが、
自分を売るという意味にもなる、というのを最近認識した。
あと売ってる人たち書いてる人たちが楽しそうというのもある。
ぶっちゃけ超マニアックな謎な書籍とか超初心者向けの書籍も結構置いてたりするので俺がショボい本出しても別にいいだろ感もある。
どういう流れでサークル出場すんだか全然知らんけど。やるとすれば半年後にGCP関連の書籍を個人で出すとかだろうか?
待ってろよ、技術書展7……!