投稿

2018の投稿を表示しています

DDDと私

イメージ
Table of Contents最初にDDDとの出会いDDDに近づく。オブジェクト指向に興味を持つDDDと再び出会う現在、DDDとともに
最初に こんにちは moai です。
この記事は、ドメイン駆動設計 #1 Advent Calendar 2018 の7日目です。

昨日は、@kawakawa さんによるドメインオブジェクトとユースケースの関係についてでした。
今回は私とDDDの話をしようかなと思います。

ここでは、手法の話はしません。
手法の話をご期待の場合は、ご期待には沿えませんので、どうぞこちらでおかえりください。 DDDとの出会い 私がDDDに出会ったのはおおよそ二年前のことでした。
Amazonの購入履歴を見るに、わたしは2016/02/21にエリック・エヴァンスのドメイン駆動設計を買ったようです。

しかし、その時は第一部を読んで満足したような気がします。
ざっくり言うと良さがあんまりわからずに、途中で読むのをやめちゃったんですね。

だって、分厚いんだもの。

そのころ、私は新規開発をたくさんするようになったものの、
CRUDに非常に近い機能を作っており、 DBにうまく値を格納するかに熱心でした。

例えば、あるテーブルのデータをPDFに乗せるとか、
テーブルのデータを使って一覧画面をつくりソートするとかですね。

PDFにデータ載せて、こんなの作ったり、


一覧画面を作ったり。(これは弊社の今の画面なので、とても奇麗ですが昔はもっとおぼこい感じでした。)




そのため、そのころ読んでいたのはData Modeling Resouce Bookという
世の業務アプリケーションで使われているモデリングはこうなっているんだよという本を熱心に読んでいました。

そのころ思っていたこととしては、 うまくテーブル設計できていれば、
モデルの設計はあとからちゃんとついてくると信じていました。
何なら、DDDなんか知らなくても、俺は俺の最強のアプリケーション作れると信じていました。
そして、なんなら英語の本まで参照しちゃう俺すごい、くらいに思っていました。

今思うと、それは正しい局面もあれば、少し複雑になると正しくない局面もあると教えてあげたいですね。

若さ。

そんなこんなで私はDDDと出会いはするものの、
すぐに興味をなくし、
データモデリングという違う技術にご執心でした。 …

テンプレートを定期的にコピーするスクリプト

イメージ
なにこれ? タイトルの通りのスクリプトを作ってみる記事。 困っていたこと ざっくりいうと G Suiteとか業務で使っているとテンプレートファイルを作って、それをコピーして使うようになるじゃないですか。 ただ、そうすると毎回、ファイルを右クリックして、コピーしてファイル名書き換えてとかするわけですよ。 めんどくさい。 具体的に言うとこうして(テンプレートファイルを右クリックしてコピーして) こうして(右クリックして、ファイル名書き換えて) こうする(はぁ、やっとほしいもんが得られた) 作業がめんどくさかったわけです。 そのスクリプトスクリプトの設置方法 事前手順 Googe App Scriptのアプリは事前に追加しておいてください。 『アプリを追加』から追加する  Google App Scriptを接続しておく 手順 そこのディレクトリに行って、ファイル追加と同じ要領で追加してください。 (そこのディレクトリにいく必要はホントは無いけど、運用的にはそこディレクトリにおいておくのが後々のわかりやすさから親切だと思います。)

「決断の本質」をおすすめする

この記事は、以下の本がとう良かったのかを書いた記事です。


サマリー
この本はここ半年で読んだ中でベスト3に入るいい本。物事が決まらんなーと困っている人にぜひ読んでほしい。こんなことが書いてあるよい意思決定とは何か?意思決定に対するベストプラクティス意思決定のベストプラクティスの運用
こんな人には役に立つと思う
こんなシチュエーションを抱えている人にとっては役に立つと思います。

物事は決まらんことが多いと感じている人。決まったと思ったら、後で議論は紛糾するなどを何度も経験した人。決断はいつもやりずらく、どのような順番で、何をどうやって決めていったらいいのかわからない人意思決定をスムーズに進める本とかないんか?とか思っている人 結構あるシチュエーションだと思います。私も明確な正解がない状況で、決断を下すというのは非常に難しいなと思います。特に決断を下すこと自体は決めの問題ではあります。しかし、それがチームに支持され、その決断に従ってチーム全体が行動する、そんな決断をスピーディーにしっかりと決めていくのってほんとに難しいと思います。
だからこそ、この意思決定の手法が存在すること自体に意義がありますし、事例が明示されてることによって、ある程度の確かさも与えてくれています。

どのような場面で役に立つのか? こんな場面で役に立つと思います。

何をどのように決めたらいいのかわからなくなって、決めることができなくなってしまっているとき。いくつかの意見が出て、個々の意見にに誤りはない。ただ、すべてを実行することはできず、どれか一つもしくはいくつかを選べないといけないとき問題すらよくわからず、不透明な状況で物事を決断していかなくてはならないとき何かしらの決定案をブラッシュアップするためには案を出して、それを批判して、洗練させていくプロセスを踏めばよいのは、暗に感じている。しかし、それって本当にそうなのか明確に認識していないとき。この本ではそれが有用に作用している例を提示しています。案を出す、批判するっていうプロセスって、個人的な感情的な対立を産んだりするので、扱いが怖いと思っているとき それをどのように使っていくのか、いつが使い時なのかが提示されています。
また、建設的に解決するためには、どのようにすればよいのかということについても言及されています。
人が困るのは明確な答えがない状況です。…

レビューの目的を設定して、レビューを建設的にしよう

イメージ
最近レビューについては、どのようにやっていけばいいのかなーと思うことがあって、 本を読んでいくことにしたところ、 ある本にとても良いアイデアがあったので、紹介したいと思います。

今回読んだ本はこちらです。

そのアイディアとは、レビューの目的を『修正工数を減らすこと』とすることです。

この本は設計に関するレビューの話ですが、一般的なレビューについても応用できると思います。 レビューの目的とは?まずこの本では明確にレビューの目的を定義しています。
これが大変すばらしいと思い感銘を受けました。

この本で記載されているレビューの目的とは

修正工数を減らすこと

です。

なぜ目的を定義することがすごいと思ったのか?レビューの目的の言語化自体がすごい

レビューの目的を明確に定義されている人は多くないのではないでしょうか?
つまり、それを言語化しただけでもとても意味があることだと私は感じました。

例えば、レビューをするときにこれは本当にここで指摘することなのだろうか? とためらった経験はありませんか?

ロバストネス分析をやってみるとモードレスっていうのはAPIも単純になっていいなと思った

イメージ
そもそも 私、設計スキルを学ぼうと思っていて、本とか読んで、インプットだけはやっていたんですが、設計スキルを発揮するにふさわしい複雑な問題には出会ったことがなかったです。 もともと設計というプロセスを挟むことによって、時間はかかるようになるし、いつでもどこでも必要とは思っていないです。 いろいろ本を読んだ今でも、設計プロセスをむやみやたらに挟むのは良くない派です。 とはいえ、設計プロセスの一つである、ロバストネス分析をやってみると問題が単純化するよという例が得られたので、今回記事を書いてみることにしました。 今回考えた問題 こんなUIが与えられているとします。(Google Keepに保存ボタンがついているものです。) このUIでは、何かしらリストを追加したり、リストの内容を変更したりすることができます。

保存ボタン付きのリスト。リストの一行に保存ボタンがついているのではなく、リストを含むセクション全体に対して、保存ボタンがついている。
何やら、複雑そうな気がします。 ロバストネス分析をやってみるとどうなる? これを一度ロバストネス分析をやってみることにします。 以下の図において、赤い丸が、ユーザが行う操作で、緑の丸がブラウザ上におけるエンティティです。 また、グレーの丸がサーバ上のエンティティになります。 複雑度がお分かりいただけたでしょうか? 注目は赤枠で囲われている箇所です。 このUIだと、フロントでサーバ上のリストにある要素か、ない要素かを保存しておく必要があって、実装が複雑になりそうです。 また、APIとしてもRESTだけで表すことはできず、どうしてもリストに削除フラグなどを仕込んで、削除フラグが立っているリストの要素に対してだけ、削除を実施するなどの工夫が必要です。 私はこのロバストネス分析をやってみた結果、この実装はやりたくないなと思いました。 で、どうしたらもっと単純な実装になるUIになるのかなと考えた結果、世の中のリストUIを見ているとリスト全体を含む塊には保存ボタンがついていないことに気づきました。 つまり、モードレスなUIです。 で、モードレスなUIにするとどうなる?