「DDD Alliance! ドメインオブジェクトの見つけ方・作り方・育て方」へ行ってきた
先日参加したのでまとめを書きます。
- タイトル: DDD Alliance! ドメインオブジェクトの見つけ方・作り方・育て方
- 日時: 2016年5月25日(水) 19:00 - 21:00
- 会場: 株式会社ドワンゴ 銀座松竹スクエア 13F セミナールーム
- URL: http://ddd-alliance.connpass.com/event/31834/
- 資料: http://www.slideshare.net/masuda220/ss-62386442
メモ
- 設計の基本
- アジャイルとオブジェクト指向のつながりはたまたまではない。
変更容易性を突き詰めていった結果の側面。 - 仕様変更とプログラムの変更が一致しないのはダメなモジュール。
モジュール性における連続性が低い。 - 機能分割が機能クラス+データクラスなら、オブジェクト指向は抽象データ型。
- メイヤーの本は鈍器。
- 機能分割はモジュール評価における「わかりやすさ」や「連続性」が低いので変更が大変。
(メイヤーによると) - オブジェクト指向なら変更に強いので仕様変更が怖くない。
むしろお客さんの興味のあったことを理解できたはずなのでムダではない。
- アジャイルとオブジェクト指向のつながりはたまたまではない。
- 見つけ方
- 何気ない用語からドメインの学びは始まっている。
- 利用規約はドメインそのもの。クラスやその振る舞いの要素そのもの。
- アソビューはDDDで開発している。CEOの理解もある。
- とりあえずひな型8点セットや業務の関心事発見パターンを参考にする。
- 作り方
- getして自分で判断・加工・計算するのはNG。
これによりロジックの置き場の整理にもつながる。 - nullを渡さない戻さない。全員が守れればチェックはいらない。
信用できずにチェックをするとなると、それによってコードが汚れるので、
可能であれば約束事にすべきだ。 - ドメイン層以外は常にシンプルにしておく。
ドメイン層以外が汚くなったらそれは怪しい箇所としてチェックできる。 - DBや画面はデータをどう扱いたいかだけだからデータをフラットにしたがる。
オブジェクト指向と相容れないのは仕方が無い。 - ドメインの表現にこだわるためにフレームワークを活用する。
ドメインが守れるなら、多少の苦労はいとわない。妥協しない。
- getして自分で判断・加工・計算するのはNG。
- 育て方
- メソッドの抽出を頑張る。
- 2個以上の引数は怪しい。
- 一時変数を値オブジェクトへ。
- 区分オブジェクト。
- QA
- コンテキストを超えた範囲での共通化をどうするのか。(名前、電話番号など)
- コピーがいい。コンテキストごとでドメインが成長するので共通モジュールにしにくい。
- ドメイン層が深いとテストしにくい。
- 深い階層になるのはドメイン設計に問題がある。
(増田さんは)ドメイン自体にテストは書かない派。サービスなどはテストを書く。
- 深い階層になるのはドメイン設計に問題がある。
- コンテキストを超えた範囲での共通化をどうするのか。(名前、電話番号など)
所感
- メイヤー本の話が出た。
昔オブジェクト指向を深く知りたくて読んだけれど、理解できなかったり読み飛ばしたりしたところが多かったのでもう一度トライしてみたい。
いやDDD本の再読の方が先か。 - 「オブジェクト指向なら変更に強いので仕様変更が怖くない。
むしろお客さんの興味のあったことを理解できたはずなのでムダではない。」あたりは増田さんらしい。(他ではあまり聞けない) - nullを渡さない戻さないは挑戦しているけれど、チェックしないという発想はなかった。
習慣でLombokの@NonNullつけていたけれど 信用できる範囲内ならいらない気がする。
挑戦してみよう。 - 個人的にオブジェクト指向エクササイズのルール9の考え方(getterを使わない)が
曖昧なことに気がついた。
例えば、商品価格、数量、割引率があって総合価格を計算するときに、どっかにまとめて計算するメソッドを作ってgetしてしまいそう。
そこからのリファクタリングがぱっとは浮かばない。自身の中で整理が必要。 - 今回は最終補欠が24人いた。次回以降、普通に落選して繰り上がれないことも覚悟が必要。
謝意
増田さん、DDD Allianceさん。このような会を定期的に開いていただいて感謝します。
次回も期待しています。
オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)
- 作者: バートランド・メイヤー,酒匂寛
- 出版社/メーカー: 翔泳社
- 発売日: 2007/01/10
- メディア: 単行本(ソフトカバー)
- 購入: 11人 クリック: 307回
- この商品を含むブログ (130件) を見る
「JJUG CCC 2016 Spring」へ行ってきた
「JJUG CCC 2016 Spring」へ行ってきたので
参加報告を(初めて)書きます。
- 日時: 2016年5月21日(土)
- 会場: ベルサール新宿グランド
- URL: http://www.java-users.jp/?page_id=2377
GH-1 Type Annotation for Static Program Analysis
まとめ
- Java7までは宣言にしかアノテーションを書けなかったが、Java8以降では型の使用に対してもアノテーションを書けるようになり、振る舞いもチェックできるようになった。
- これまでのFindBugsではパターンマッチングしているだけなので、振る舞いに対してはチェックできない。しかし、Java8以降であれば振る舞いに対してもチェックできるようになっている。
- 例えば、CheckerFrameworkの@Nullable等。
所感
- とっつきにくい話もわかりやすくまとめる桜庭さんのすごみを感じた。
- アノテーションの幅が広がって何かに使えそうだけれど、それを研究する余裕が無い。いつかやる。
F-2 Thymeleaf 3 を使ってみよう!
まとめ
- Thymeleaf3が5/8にリリースされた。
- Full HTML5対応により、閉じタグを完璧にしなくもOKになった。
(brの閉じタグなしは2ではエラー。) - テキストモードにより、タグより簡素に書ける場面が増える。
- 大幅な内部リファクタリングによりパフォーマンス改善。
- 5/21現在ではThymeleaf3がspring-bootに対応していないので、少々設定が必要。
- 大きな新機能はないので特殊な機能を使っていない限り、2->3はほぼ問題ない。
所感
- スピーカーの椎葉さんは、Thymeleafの日本語訳も書かれたかただったのは知らなかった。
よく使っています。感謝します。 - 3以外にもThymeleafの大まかな説明をしてもらい、なんとなく使っている部分やはき違えていた部分もあったので自信が持ててよかった。
- 6月になったらSpring-boot1.4と共にThymeleaf3に行くしかない。
E-4 テストゼロからイチへ進むための戦略と戦術
まとめ
- いきなり完璧にしようとせず、チームの立ち位置と着地点を確認する。
- テストを手動でやろうが自動でやろうが綺麗に表示を確認できるデータは必要なのだから、かならず用意する。
- テスト自動化以外でも使えるツールを使う。
- 便利なプラグインを導入する。
- カバレッジは7割ぐらいを目指す。ただ重要なのは増減の推移。
- 絶対防衛ラインだけSelenumuにするなども考える。
- テスト以前に環境構築の簡素化は必要。
所感
- 要点を押さえて話してくださるのでとても聞きやすかった。
- テスト自動化と開発環境の簡素化は近いところにあるという考え方が勉強になった。 テスト自動化以前に開発環境簡素化を進めておいて、テスト自動化を徐々すすめるアプローチもありかも。
GH-5 Spring Framework/Bootの最新情報とPivotalが進めるクラウドネイティブなアプローチ
まとめ
- spring-boot1.4
- 2016年6月予定。
- テスト向け機能が改善。
- Spring Framework 4.3
- 目新しいモノよりも改善が多い。
- @autowiredなしでのインジェクションが可能になる。
- GetMappingや@sessionAttribute等が追加。
- Spring5
- JDK9対応。
- Reactive関連が追加される予定。
所感
- 「はじめてのSpring Boot」を書かれた槙さんの発表。pivotalに行かれたのか。
- @autowiredがいらなくなるのは、とてもうれしい。リリースが待ち遠しい。
E-6 大規模映像配信サービスのJava8による全面リニューアルの裏側
まとめ
- U-NEXTがPHP→Javaへリニューアルした。
- DBFluteを中心としていった。
所感
- SQLの個人差を嫌ってDBFluteを選んだみたいだけど、DBFluteへ強く依存している気がする。
- DBFluteのコミッターの人が色々対応していたみたいな話をしていたが、その人が飽きたり、病気になったり、うまく次の世代へ引き継げなかったりしたらどうするのだろう。
- そんなこと考え出すとSQLが一番長生きしていて安全なのか。しかしあの規模感のシステムでSQLを書きたくない気持ちもわかる。
AB-7 若者にJavaの好きなところ嫌いなところきいてみた
まとめ
- 静的型付けが強力。
- public static final など冗長なものも多い。
- JVMとライブラリの恩恵が大きい。
- コミュニティが多数で大規模。
- VIMで使いにくい。
- GCがあるのでリアルタイム処理は難しい。
- かっこいいGUIがない。
- 歴史が長すぎて覚えることが多いし、バージョンの積み重ねによる経緯がわからない。
- 選択肢が多すぎるが故に決定が難しい。(フレームワークの選定など)
- くそコードが多い。くそコードしか知らずに(それが正しいと思って)育ってしまう。
所感
- 私は若者側ではないので参考になった。
- 聴衆に聞くのはよいが、そんな場合はスライドを前日でもいいので公開していただけると答えやすいと思う。その場で考えをまとめて発言できる反射神経の良さもっている人は限られる。
- その場では答えられなかったので、回答を考えてみた。
- 「くそコードしか知らずに育ってしまう」件については、そのことに対する問題意識があれば救える可能性があるが、ない場合は救えない。
- 問題意識がある場合は他の人のコードをたくさん見ることをお勧めする。その中でこれはいい、あちらはよくないがわかってくる。その中でいいと思った書き方を真似ればいい。「リファクタリング」や「リーダブルコード」のコードの書き方の本もお勧め。組織にくそコード改善が期待できなければ転職を考える。
- 問題意識がない場合は気づいてもらうしかない。例えば日本が鎖国を続けて下駄しか知らないということになると、下駄で何が悪いということになる。シューズ(靴)を知って、初めて下駄が履きにくいということになる。閉じた世界ではくそコードもくそコードで何が悪いということになるので救えない。シューズの存在を知り、下駄は履きにくいと考え出すまでは救うことができない。
くそコードを書いている組織やエンジニアは効率が悪いから淘汰されそうな気がするが、必ずしもそうはならない。結局は自ら問題意識をもって改善していくしかない。(他力を期待しても他人がやってこないこともある)
全体の感想
- 休み時間が増えてよかった。
- アンケートとセッション案内の紙を分けてほしい。
セッション案内の紙を持って返りたい。 - 時間が被らなければ参加したかったセッションは多かったので、
ラインナップが充実していると思う。 - ただ見られなかったものも多いので、いずれはビデオに撮って配信もしていただけると最高。
最後に発表者とスタッフの皆さんに感謝します。
ここ毎回着実にレベルアップや改善がされていると思います。
今後も期待しています。
トピック「JJUG」について