tsalakh ain sus noam Huyah ol guf

勉強会のメモ。その他備忘録。参考にさせて頂いたサイトや資料はリンクさせて頂いていますが不都合があればご連絡ください。

【勉強会】JJUG CCC Fall 2016その2

JJUG CCC Fall 2016

これに行ってきたその2、聞けなかった編

www.java-users.jp

資料はここ

github.com

基調講演1

「Be a great engineer!〜 フォローすべきトレンド、スルーすべきトレンドをどう見抜くのか」

アクロクエスト 谷本心さん

speakerdeck.com

審美眼を磨くために必要なこと

  • 自分で考えること(このセッション聞きに来てる時点でダメ)
  • 技術の本質は何かを考えること

いきなり本質はわからない

本質は、手を動かし、学び、考え抜いた先にある

  • 体:チュートリアル、入門書
  • 物:書籍、ブログ
  • 知:ブログ、コミュニティでの「発信」
  • 心:コミュニティでの「対話」
  • 理:自分で考える

人から聞いた「理」ばかりを語るのは空虚

技術には必ずニーズが伴う

面白そう、だけではトレンドにならない 己のニーズと、世間のニーズ

破壊的イノベーションは、「世」のニーズがないところに現れる しかし、「己」のニーズがあるから利用することになる 「世」のトレンドに振り回されず「己」のニーズで考える

つまり、技術の審美眼とは、

技術の本質を理解し、己のニーズに合致したものを選択することで磨かれる


基調講演2

JavaEE, What's Next?

www.slideshare.net


ドメイン駆動設計とScala

〜既存プロジェクトへの適用〜 株式会社ビズリーチ 角谷文康さん

www.slideshare.net

DDD/Scala

既存PJにDDD適用させてカオス脱却した話 Scalaの紹介

担当システム

DDDは取り入れてなかった 作りが複雑で機能追加は精神的苦痛のレベル 機能追加は今後どんどん発生する

複雑性はどこから?

複雑性は、技術的なものではなく、ドメインそのものである ソフトウェアにおけるこの中心的な側面を体系的に扱わなければならない

Why DDD?

ドメイン意識

常にドメインモデルを意識することで、行き過ぎた単純化、汎用化を防ぐ

複雑性

Serviceにビジネスロジックをまとめすぎて肥大化することを防ぐ

責務明確化

ドメインモデルに従うことで、処理が散らばることを防ぐ

設計思想統一

思想を統一することで、実装・レビューの品質を保つ

ビジネスロジックへの集中

ソフトウェアの関心事とビジネスロジックの関心事を分離する

SlacaとDDDは相性がいい

らしい

既存システムの問題点

  • モデル定義に思想がない
    • どのモデルがいったい何のためのモデルなのか、明確じゃない
  • 大きすぎる集約
    • 一つのclassでデータ持ちすぎ
  • ドメインモデル貧血症
    • モデルがメソッドをほぼ持っていない
    • XXService、XXUtilにビジネスロジックが散らばっている
    • ソフトウェアの関心事とビジネスの関心事の分離ができていない

モデルの再定義

ユビキタス言語

業務領域についてよく知った人との会話においても、お互いに齟齬なく情報を伝えあうために用いることができる言葉を定義したもの。

世間一般で通じる言葉を用いる必要はない 境界づけられたコンテキスト内で通じる言葉ができればいい

専門的な用語が、本当に求めているものを表しているとは限らない なるべく齟齬を減らすために、自分たちで言葉を再定義する必要がある チーム全員がその言葉を聞いて勘違いすることなく、同じ物事を思い浮かべることができるまで言葉を洗練するのが重要

境界づけられたコンテキスト

対象とする範囲が異なれば、ドメインモデルは意味をなさなくなる なので、初めに自分tナチの定めようとするドメインモデルがどのコンテキストに関するものなのかを定義する必要がある

ドメインを見つけ出し境界づける 自分たちの事業のドメインは何なのか(採用管理、勤怠管理、評価管理、、)

コンテキストマップを描く それぞれのドメインが担うべき役割を明確に分ける ドメインモデルがどこに属するかを明確に表す 境界は、チーム構成、コード、DBスキーマなど物理的な観点を踏まえること 境界の内部では、モデルを厳密に一貫性のあるものに保つこと 境界の外部の問題によって影響を受けないようにすること

ドメインモデルを見つけ出す

ユビキタス言語ができたら、そのことばをドメインモデルに落とし込む

  1. Entity
    • 同一性を識別することが必要となるモデル
    • 簡単にいうと、他と区別するためのIDを持たせて管理すること
  2. ValueObject
    • イミュータブルに保つ(状態を管理しない)値
    • 状態を持たないことで、複雑性の排除に役立つ ど
  3. Aggregate

EntityかValueObjectかは、主体によって変化する 例えば「1000円札」は、一般人にとってはValueObject、日本銀行にとってはEntity


JPA と DDD の関係で僕が思っていること

Opengl-8080さん

qiita.com


Selenideを試行錯誤しながら実践するブラウザ自動テスト

うらがみさん

Try Selenide


JVMのトラブル解決のためにやったこと~メモリー/スレッド

岩佐淳史さん


Spring Cloudアプリケーションの開発にDockerを活用し、Kubernetes上にデプロイするまで

村田賢一郎さん

speakerdeck.com