より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
Koichi Sakata (じゅくちょー) @jyukutyo Javaでメソッドの引数がOptional<Hoge>型のときでも、やっぱり引数のnullチェックいるよね… 2015-11-20 15:50:00
昨日、Spring MVCのOptionの使い方がカッコイイという話で、こんなコードを書きました。 @RequestMapping("/") public String hello(@RequestParam("name") Optional<String> name) { if (name.isPresent()) { return "Hello, " + name.get(); } else { return "Hello, John"; } } そしたら、多方面から切れ味するどいツイートが飛んできました あー。 そんなわけで、今回の例で言えば、こう書くのがカッコイイと思います。 @RequestMapping("/") public String hello(@RequestParam("name") Optional<String> name) { return "Hello, "
The document discusses various techniques in Perl for dealing with reference cycles and memory leaks caused by strong references, including using weak references, extracting needed data from objects before destroying them, and passing objects into subroutines to avoid capturing them. It also discusses analogous techniques used in Objective-C like weak references and guard objects to break cycles.
こんにちわ、みけです。 2014/10/10のScala勉強会に向けてScalaをやってたら、 Optional<T>の自分でもいいと感じる書き方がわかってきたつもりなので、 メモ書きしておきます。 Optional<T>を使うときの自分的なベストプラクティス。 #isPresentは使わない 極力#map(Function<T, R>)や#filter(Predicate<T>)や#flatMap(Function<T, Optional<R>)を用いる 最後に#orElse(T)、#orElseGet(Supplier<T>)を用いる #isPresentは使わない これは使わないというよりは、むしろ、 使う機会がほとんどない感じがします。 最初、Optional<T>を使ってみたときは、 これまでのnullチェック脳の延長で 下のようにすぐifにぶっこんでいました。 int port
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
