こんにちは、ソリューション開発部の瀧口です。

先日、DBFluteフェス2016に参加してきました。
当日は40名もの変態(褒め言葉)が集まる中、なんと飛び込みでLTをさせていただきました!

快く受け入れて下さった @jflute さんはじめ、発表を聞いていただいた皆様、また会場提供およびスタッフとしてフェスを支えていただいたビズリーチの皆様に、この場を借りて改めてお礼を申し上げます。本当にありがとうございました。
@jfluteさんのブログで当日の模様が詳しく書かれているので、当日参加できなかった方や、DBFluteやLastaFluteに興味のある方はどうぞ!

さて、私のLTタイトル「DBFluteを閉じ込めよう」ですが、実際にはDBFlute関係なくオブジェクト指向の基本であるカプセル化、責務の分離をちゃんとやろうね、ということだったりします。作るときにはサクサクっと作れたものが、いざ改善・修正しようとしたときに思わぬ副作用が発生したこと、誰しもあるのではないでしょうか。

特にDBFluteを使ったときは、SQLがあまりにも簡単に実行できてしまうが故、あちこちからDBアクセスしがちになり、結果としてDB仕様と業務仕様があちこちに分散してしまいます。一つの修正が意図せず他の機能に波及したり、逆に1つのバグを直したいのにあちこちの機能に手を入れたりというのは、あまりうれしいことではありませんね。

このような状態を防ぎ、継続的な改善を可能とするにはどうしたらよいのか。私たちも試行錯誤を繰り返している最中で、全然ゴールに到達していません。ゴールなんて無いのかもしれません。それでも、日々の繰り返しの中で得られた気付きを、ご紹介出来ればなと思います。

当日のスライドはこちらです。


 

依存関係を反転させるところ、私のつたない説明よりも、「ヘキサゴナルアーキテクチャ」を調べていただいた方が早いと思います。エリック・エヴァンスのドメイン駆動設計を読んでから、具体的にどうコードに落とし込んで行くべきか悩んでいた時に出会い、「これだ!」と思いました。

IoC (Inversion of Control. 制御の反転)という単語は知っていたし、DIコンテナも日常的に使っていたのに、「単体テストでモックと差し替える」くらいにしか使えていなかったんですね。

そんないまさらな自分の気付きですが、少しでも皆さまのカイゼンのお役に立てたらうれしいです。

スライドの最後の方、本当は具体的なコードを入れたかったのですが、PCを持っておらずiPhoneのKeynoteで作っていたため断念しました。Mavenのモジュールをruntimeスコープで抑えつけるとか、Spring BootのAutoConfigurationとか、どこかで改めて記事にまとめたいなと考えています。

それでは。

 

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

Twitter で「株式会社アークシステム」をフォローしよう!

DBFluteフェス2016でLTしました!https://devlog.arksystems.co.jp/wp-content/uploads/2016/12/dbflute-fess-2016.jpghttps://devlog.arksystems.co.jp/wp-content/uploads/2016/12/dbflute-fess-2016-150x150.jpgtakiguchiソリューション開発部セミナー・イベントJava,カイゼン,勉強会,DBFlute,LT(ライトニングトーク)こんにちは、ソリューション開発部の瀧口です。 先日、DBFluteフェス2016に参加してきました。 当日は40名もの変態(褒め言葉)が集まる中、なんと飛び込みでLTをさせていただきました! 快く受け入れて下さった @jflute さんはじめ、発表を聞いていただいた皆様、また会場提供およびスタッフとしてフェスを支えていただいたビズリーチの皆様に、この場を借りて改めてお礼を申し上げます。本当にありがとうございました。 @jfluteさんのブログで当日の模様が詳しく書かれているので、当日参加できなかった方や、DBFluteやLastaFluteに興味のある方はどうぞ! さて、私のLTタイトル「DBFluteを閉じ込めよう」ですが、実際にはDBFlute関係なくオブジェクト指向の基本であるカプセル化、責務の分離をちゃんとやろうね、ということだったりします。作るときにはサクサクっと作れたものが、いざ改善・修正しようとしたときに思わぬ副作用が発生したこと、誰しもあるのではないでしょうか。 特にDBFluteを使ったときは、SQLがあまりにも簡単に実行できてしまうが故、あちこちからDBアクセスしがちになり、結果としてDB仕様と業務仕様があちこちに分散してしまいます。一つの修正が意図せず他の機能に波及したり、逆に1つのバグを直したいのにあちこちの機能に手を入れたりというのは、あまりうれしいことではありませんね。 このような状態を防ぎ、継続的な改善を可能とするにはどうしたらよいのか。私たちも試行錯誤を繰り返している最中で、全然ゴールに到達していません。ゴールなんて無いのかもしれません。それでも、日々の繰り返しの中で得られた気付きを、ご紹介出来ればなと思います。 当日のスライドはこちらです。  依存関係を反転させるところ、私のつたない説明よりも、「ヘキサゴナルアーキテクチャ」を調べていただいた方が早いと思います。エリック・エヴァンスのドメイン駆動設計を読んでから、具体的にどうコードに落とし込んで行くべきか悩んでいた時に出会い、「これだ!」と思いました。IoC (Inversion of Control. 制御の反転)という単語は知っていたし、DIコンテナも日常的に使っていたのに、「単体テストでモックと差し替える」くらいにしか使えていなかったんですね。 そんないまさらな自分の気付きですが、少しでも皆さまのカイゼンのお役に立てたらうれしいです。 スライドの最後の方、本当は具体的なコードを入れたかったのですが、PCを持っておらずiPhoneのKeynoteで作っていたため断念しました。Mavenのモジュールをruntimeスコープで抑えつけるとか、Spring BootのAutoConfigurationとか、どこかで改めて記事にまとめたいなと考えています。 それでは。ARK Solution Development Division Developers Blog.