見出し画像

2019-05-18 JJUG CCC 2019 Spring #jjug_ccc

2019/05/18 に開催された JJUG CCC 2019 Spring のイベントレポートです。

●イベント概要
JJUG CCCは毎年2回、春と秋に開催する日本最大のJavaコミュニティイベントです。Java関連の技術や事例に関する良質なセッションが行われ、また異なる分野で活躍するJava技術者が一堂に会する場ともなっています。ぜひご参加ください。


■Jakarta EE Update - May 2019 -

蓮沼 賢志 さん

●Jakarta EE
・server-side javaの標準規格
・jakarta EE working groupが主導
  eclipse foundation配下
  コミュニティが主導で進めている
・java EE 8 を引き継いだもの

●Jakarta EE WG
・strategic members
  Fujitsu, IBM, Oracle
  Payara, Red Hat, Tomitribe

●Java EE to Jakarta EE
・owner
  Oracle -> Eclipse foundation
・standardise
  JCP -> JESP
・specification
  JSR -> EE4J Project

●Schedule
・2019-01-29 oracleから資産が移った
・Jakarta EE Spec process
・Jakarta EE 8
・Jakarta EE 9
  ここから加速します!

●Donations from Oracle
・GlassFish & sub projects
  GlassFish, jersey, mojarra
  grizzly...
・Java EE 8 TCK

●GWに名称の合意が取れた
・方針
  Java EE -> Oracleのtrademark
  javax.* -> Oracleのcopyright
・対応
  Java EE -> Jakarta EE
  javax.*
    -> javax.*
      一切弄らないなら
    -> jakarta.*
      一切変えないということはないはず
      徐々に変える?一気に変える?の話し中

●Jakarta EE 8
・Java EE 8 との差はほとんどない
・eclipse glassfish 5.2
・2019秋ごろリリース予定

●Jakarta EE 9
・APIのテコ入れが入る
  JSF 3.0
    CDIとの結びつきが強くなる
    2.3に残っていた古い機能を廃止
  Security 1.1
    積み残し部分を強化
  JASPIC 1.2, JACC 1.7
-> 手が入るのでpackage名が変わるはず

●コード見せてません
・Jakarta EE 8 は Java EE 8 のコードのまま
・Jakarta EE 9 でも残るはず

●でも、心づもりは必要
・Java EE -> Jakarta EE に変わる
・Jakarta EE の開発は圧倒的に早くなる
・Jakarta EE はこれからつくっていく仕様

●リンク
・Jakarta EE Home
  https://jakarta.ee
・Blog
  https://jakartablogs.ee

●Q: ベンダーの動きで見えていることはありますか?
・Java EE 8 に対応しているベンダーは
  Jakarta EE 8 に対応していきそう
・Java EE 7 までのベンダーは分からない

●個人的な思い
長く守られてきたJava EEの互換性が崩れる
oracleは愚直に商標を守った
他は、なんとかならないかを話した
みんな損している
が、open solarisのような悲劇にはならなくて良かった


■ArchUnit で Java/ Kotlin アプリケーションのアーキテクチャを CI する

かわなみゆう さん

●自己紹介
・株式会社ラクス
・B2B SaaS x HR Techしている
・東京本社、大阪でスクラムしている
・裏セッションを再演します

●アーキテクトの悩み
・初期に頑張って検討したが
  納期優先、メンバー増員で泥団子
・コードレビューはするが、アーキテクチャのレビューはない

●開発メンバーの悩み
・どこにクラスをおいたらいいか迷う
・レビューで指摘されたけどそんなルール聞いてない

●原因
・アーキテクチャ設計の知識が属人化、暗黙知化
・知っている人が人力チェック
・知らなければすり抜けていく

それ解決できます!ArchUnitならね!

●ArchUnit
・ソースとサンプル
  https://github.com/TNG/ArchUnit
  https://github.com/TNG/ArchUnit-Examples
・Javaアプリのパッケージや依存関係をJunitテストコードで
・カスタムロジックも組める

●出会い
・進化的アーキテクチャ
・適応度関数、JDepend
  類似ツールを探してたらArchUnitを見つけた

●できること
・アーキテクチャレビューの自動化
・アーキテクチャの形式化
  レガシーコードでのリファクタ対象を見つけるのに使える!

●典型的なテスト
・レイヤーアーキテクチャ
・パッケージ、クラス間の依存
・循環参照の禁止

●レイヤードアーキテクチャのテスト
・レイヤがどのパッケージか
・レイヤにどのルールを適用するべきか
・uiは参照されない
・domainはui, appレイヤから参照される

●レイヤードアーキテクチャにDI適用
・uiはinfraから参照される
・domainはinfra,appから参照される
-> domainレイヤが、infraに依存しているなどを検出

●クラス間の依存関係
・presentationパッケージはinfraだけ
  などをfluentに書ける

●事例1: ドメイン層を独立させよ!
・実行環境に依存しない
  servlet
  springframework
  など

●事例2: commonパッケージは本当にcommon?
・独自ルールを実装
  commonパッケージが自分のパッケージ意外を参照してはならない

●事例3: アプリケーション固有のチェック
  エンドポイントには@Roleアノテーションがついているか

●事例4: 実装ミスの不具合の再発を防止
・JSONシリアライズとデシリアライズはセットで実装
  実装しないと出力の順序が変わってしまうことではまった
  他の人が踏まないようにチェックを追加


■Cloud Native時代の開発環境とアプリケーション基盤

レッドハット株式会社

●eclipse che
・ブラウザベースのeclipse

●なぜRed Hatが?
・cheを開発していたcodenvy買収から2年
  製品化した
・ブラウザベースが現実的に
  AWSのcloud9、MSのVSCodeなど

●コンテナ化されている
・デスクトップ環境の統一、セキュリティ確保は大変
・コンテナベースで集中管理された開発環境

●アーキテクチャ
・che server
・che workspace
  個々が開発者ごと
  VSCode互換のtheia
  language serverで多言語対応
・実行環境
  k8s/OpenShift/docker
    最新のdocker on Macだと
    プロキシが入って変えられないので動かなかった

●メリット
・環境構築時間が減らせる
・cheは拡張しやすい

●要素
・Web IDE
  見た目はeclipseそのもの
  メニューバーなどはちょっと癖がある
  誰かに聞かないとわからないかも
・Stack
  カスタマイズして新しいstackを作れる
  machine
    docker image
    リソース指定
    agentを設定
  commands
    指定コマンドを実行
    コンテナが動く
  components
    ラベルですw
  raw configuration
    jsonでexport/importできる
・Workspace
  stackを選ぶ
  machineを選ぶ
  projects
    git repoを指定
  -> workspace Podを起動
・Factory
  既存workspaceを共有できる
  利用中のworkspaceのcontainer imageを保存
  トラブルがあったらまるっと渡したりもできる

※Web IDE のその他1
・terminalも使えます
  日本人にはfontが残念
  コントリビュートお願いします!w
・command
  stackで定義できるが
  workspaceでも定義できる
  コマンドリストで対象コマンドを「ダブルクリック」で実行

開発者全員が使えるリソースを用意しておけば良いだけ

●入り口
・SaaS(Che on OpenShift Online)
  https://www.eclipse.org/che/
  遅いです
・Minishift(MinikubeベースのOpenShift)
  Che addonが便利
  手元のリソースにゆとりがあるならコレ

●有償サポート: CodeReady Workspaces
・OpenShiftにタダでついてくる
・operatorでサクッと
・日本語のサポートはこれから

●情報
・CodeReady Workspacesチュートリアル
  情報はRedHatのブログで
・Rd Hat OpenShift Application Launcher
  サンプルアプリ
  zipダウンロード or OpenShiftデプロイ

※Web IDEのその他2
・debug実行もできる
・git clientもついてます
  git pushできない
  メッセージが 失敗した しかでない
・トンネルをつくって手元のIDEとつなぐこともできる
  IntelliJを触って
  workspaceはche

●OpenShift 4
・5月末にメジャーバージョンアップ
  熱い!
・OperatorHub に対応
  k8sにmanaged serviceをつくるようなしくみ
  https://operatorhub.io
・Operatorをつかって管理画面もカスタマイズできる
・pipeline
  中にJenkinsを含んでいる
  TEKTONに組むように変わる

●Knative x Quarkus のワークショップやります!
・5/20(月) ですがw
・RedHat 新しいロゴになりました!
  ロゴからシャドーマンがいなくなってますw


■先行開発!Javaでクリーンアーキテクチャ -- ゼロから始める新規開発

GMOインターネット株式会社

●自己紹介
・クリーンアーキテクチャだけで4記事書いてます
・みんな開発言語がちがうワークショップをやりたい

●納期しかない
・新規開発ならよくあること
・フロント先行 & 五月雨でAPI開発
  理想はAPI, DB の後で フロント
  -> 事情で理想通りにならないことはある
・こんなかんじでよろしく
  できました
  なんか違うな〜
  やっぱコレで
  -> 想像だけで最終形にはたどり着けない

●試行錯誤が必要
・フロントのプロトタイプがほしい
・クリティカルパスを避けて先行開発するには?
-> クリーンアーキテクチャ

●その前に、ヘキサゴナルアーキテクチャ
・六角形でなくても良い
・ビジネスを中心に、周りをプラガプルに
-> port & adapter
  ポート越しに通信を行いプラガプルを実現
  ビジネスロジックを点在させない

●クリーンアーキテクチャ
・port & adapterの実装はこうしたら良いのでは?のサンプル
・オニオンアーキテクチャは内側

●Enterprise Business Rules
・Entities
・ドメインオブジェクト
  ドメインは領域
  運送業なら
  トラックや運送する人、積荷など
・エヴァンス本の最初にしれっと書いてある
  ビジネスルールを抽出するのがモデリング

●Application Business Rules
・Usecases
・アプリケーションレイヤ
  ドメインを使って、問題を解決する
  いわゆるユースケース

●Interface Adapters
・Controllers / Presenters / Gateways
・クリーンアーキテクチャの右下の図
  ※ボブおじさん説明してないけどねw

●Frameworks & Drivers
・詳細なコード、ギークなコード
・ビジネスロジックがここに依存しないように
・DIPをふんだんに使ってます

●依存の方向
・内向きだけ
・ドメインロジックでWeb, DB, UIを扱わない
・クリーンアーキテクチャ本に詳しい構造が紹介されている
  上下が入れ替わってる

●登場人物
・Controller
  名前、ロールID の文字列を受け取る
  要求するデータに入力を、内部の型に変換
  ゲームのコントローラと同じ
    ボタンを押した -> 電気信号
・InputData: DTO
  pojo
・InputBoundary: Interface
・Interactor
  Entityを生成
  repositoryで保存
  outputを生成
  presenterに渡す
・Entities
  ドメインモデル≠データモデル
・DataAccessInterface: Interface
・DataAccess
  インスタンスの永続化、再構築
・OutputData: DTO
  pojo
・OutputBoundary: Interface
・Presenter
・ViewModel
・View

●やりたいこと
・流れを一方向に揃える
・人はベクトルだと理解しやすい

●フロント先行開発
・Interactorをスタブ実装
  例外を試す時も、throwするだけでOK
・データベースも最後の一週間で届いた

●楽ではない
・MVCFrameworkでPresenterの戻り値問題
  Interactorがコールしてデータを渡すか
  戻り値でデータを渡すか
  -> Presenterを捨てた。
    Controllerで変換するが、ドメインは守られる
・Inject Hell
  Commandをつくる = 結果がほしい
  MessageBus Pattern
    入力の型で出力の型がわかる
・つくるものが多くて退屈
-> NORIOをつくった
  DI設定
    debug, prod用
  JsonsLoader
    レスポンスごとにjsonファイルを変換

●先行開発
・ツールでスキャフォールディング
・jsonを書き換えてフロントを進める

●アーキテクチャの目的
・電車のレールのようなもの
  道を用意する
・自由は、ときに冒険になる
  レールがあると、快適な旅になる


■Java クライント実装におけるAPIスタイル頂上決戦! 野良REST vs GraphQL vs OData vs OpenAPI (Swagger)

CData Software Japan 合同会社

※gistにリンクがまとまっています
  http://bit.ly/CDataJJUG2019S

●自己紹介
・CData Software Japan
  JDBCライブラリをつくっている会社
・MS MVP Business Solution
・web apiを叩きまくる仕事 & 趣味

●CData Software
・web apiをSQLで実行できるようにするライブラリ
  150種類以上 提供中

●このセッションの目的
・APIをつくるではなく、使う側が楽になるように
・知っているだけで楽をできるAPIエコシステムのポイントを紹介

●APIエコシステム
・立場、立ち位置で定義が変わる
・つくる側、使う側、mashupのように触る側
・利用者から見るAPIエコシステム
  使う側がどれだけうまく使えるのかが製品の成功の鍵

●WebAPIのサービスを中心に広がる
・プロトコル
  ここの話をします
・SDK
・マッシュアップした外部サービス
  IFTTTなど
  外部ユーザがアクセスできる
・3rd party tool
  ETL/BI toolなどもエコシステムの一部

●なぜAPI実装で苦労するのか
・毎回公開されたドキュメントを読み解く
・REST がプロトコルではないから

●RESTってなんだっけ?
・ソフトウェアアーキテクチャのスタイル
・仕様はドキュメントを読み解かないとわからない
・原則
  stateless
  uniform interface
  addressability
  connectability
-> RESTful と呼ぶが、原則であって、規則ではない

●実録 こんなAPIは使いづらいw
・ページングの指定方法が違いすぎる
  同じ会社でも微妙に違う
  ヘッダー vs ボディ
  page指定、nullになるまでループ
・404のはずなのに200エラー
・リソース指向と関数指向がまざっている
・リソース名が省略語すぎ
・データを取得したいのにPOST
・仕様書がPDF、Excel

●RESTから生まれる産みの苦しみ
・RESTが悪いわけではない
・Web APIやRESTではなく、もう一歩踏み出す

●Swagger(OpenAPI) Code Generate
・WebAPIを外部から定義するもの
・RESTの使いやすい環境を作ろう から生まれた
・resourceが対応しているmethodを定義
  paramは何を渡すのか
  どんな構造でやり取りするのか
・メリット
  SwaggerSpecの周辺で生まれるエコシステム
  ドキュメント生成、CodeGen、定義を読み込んでつなげるサービス
・公開しているサービス
  CloudSign, SmartHR, SendGridなど
・まとめ
  ドキュメントがわかりやすい
  実装するコストが低減される

●OData
・RESTfulをプロトコル化した仕様
・表形式のデータ操作
・Metadata Endpoint
  リソースがどれだけあるか
  モデルはどんな構造か
  などにアクセス
・公開しているサービス
  Dynamics365, SAP hana など
・多数のライブラリ
  olingo
    fluentに書ける
    metadataも取れるから、動的に処理できる
・まとめ
  APIドキュメントを確認する必要がない
  metadataで動的なデータの取得、出力

●GraphQL
・facebookが公開したweb apiのクエリ言語
・1つのエンドポイントで複数のリソース、ネスト構造にアクセス
・facebookのUI
  グループ, タイムライン, チャット, 通知
  RESTの思想で実装する場合、リソースごとにアクセス
  1つのリクエストで関係するデータを一括で取得
・公開しているサービス
  Github, shopifyなど
・まとめ
  QueryをJavaのラムダで書くことができる
  Javaでは、まだ違うかな

●比較するポイント
・メタデータ、スキーマ
・ドキュメント
・クライアントSDK

●比較したいわけではない
・仕様であること、エコシステムがあることを理解
・開発者の選択肢が広がり、スピードも上がる!

●CData JDBC Driver
・ODataでなくても、metadataを提供している
  -> 動的な処理もできる


■ゴールドマン・サックスにおけるApache Beamを用いたビッグデータ処理の紹介と実例

ゴールドマン・サックス

●ゴールドマン・サックス
・投資銀行、証券業務などを扱う金融機関
・世界中にオフィスがある
・人材構成比 Technologyが25%以上
  金融取引がシステム化されている
  差別化で社内開発
・多くがJavaでできている
・JCP Executive Committee
・OSS
  Eclipse-Collection
  reladomo
  obevo
  https://github.com/goldmansachs

●Apache Beam
・googleのdataflowのOSSを寄贈
・Batch + strEAM -> BEAM
・Runnerの対応
  Flink, Spark, Google Cloud Dataflow
・複数言語に対応
  java, python, go

●モード
・Batch
  bounded
  データセットが変わらない
・streaming
  unbounded
  データセットが限定的でない、可変
-> オプションの変更だけで両方サポート

●なぜ使い始めたか?
・FXレートのような可変のものを扱う場合、設定だけで対応したい
・メリット
  Batch/Stream両方対応
  ポータビリティ
  ランナーによる変換
・デメリット
  Sparkなど固有のライブラリは使えない
  Spark, Flinkで細かい制御はできない

●概念
・PCollection
  データの集合体
・PTransform
  PCollectionに適用する処理
・Pipeline
  PCollectionとPTransformを集めたワークフロー

●流れ
・Pipelineの作成
  開発中はSDK付随のDirectRunner
  本番はSpark, Flinkなど
  設定を切り替えるだけ
・ビルトインIOトランスフォーム
  File-based
    HDFS, S3, GCS, Filesystem
  Messaging
    Kafka, JMS, AMQP
  Database
    Cassandra, HBase, Elastic, MongoDB, JDBC
  ※ライブラリも豊富
    TextIO, KafkaIOなど
    日本語の情報は少ないが便利
・データの変換処理
  ParDo
  in, outを指定

●Beam SQL
  Apache Calcite
    クエリオプティマイザがBeamに最適化
  SqlTransform
    SqlTransform.query(クエリ)
  RowとSchema
    DBの1列のイメージ
    fluentにメタデータを定義
    動的にも作れます

●実行するまでの流れ
・Pipelineを作成
・Pipelineを設計
  読み込み
  変換
  出力
・Pipelineを実行

●Flink
・スケールアウトはお任せ
・Dashboardでどこでどれだけ時間がかかったかも見れる

●Beamを使ったシステム
・開発の背景
  毎月1000以上のレポート
  ビジネス部門はプログラマにスクリプト作成を依頼
  コストが高い、管理しにくい
  -> self serviceへ
・システムの構成
  master
    UI
    API - Mongo
      - DataSource
    Beam
    Flink - NAS
  slave
・システムの動き
  BeamのCoreTransform
    ParDo, GroupByKey, CoGroupByKey, Combine, Flatten, Partition
  UI入力 -> SQL文字列 -> PCollection

●Beamの利点
・並列処理
・Batch/Steamingを1つのモデルで
・拡張性
・複数言語
・実行環境が多い

●Tips
・ランナーの互換性
  https://beam.apache.org/documentation/runners/capability-matrix/
・BeamとFlinkの互換性
  Beamが対応しているFlinkのバージョンを選ぶ
・SqlTransformの制限
  便利だが、CrossJoinなどは非対応


■ストラングラーパターンによるマイクロサービスマイグレーションの勘所

オイシックス・ラ・大地株式会社

●自己紹介
・オイシックス・ラ・大地株式会社
・基盤刷新の部署
・CicleCIおじさん
・API Management

●オイシックス・ラ・大地
・Oisix
  ここの話
・Radish Boya
・大地を守る会

●Scrap & Build is ...
・眼の前にときめかないコードがあります
  作り変えたら...
  何を言っているの?
・レガシーを憎んで人を憎まず

●Our EC Site
・とってもモノリシック
・とってもステートフル
・神Oracle
・独自のframework
・顧客/受注管理の2システムがターゲット

●なぜマイクロサービス?
・スケーラビリティ
  スパークすると止まる
・デリバリースピード
・テスタビリティ
  テスト動いてません

●構成
・CDNがファサード
  レガシーとAKSに振り分け
・AKS内はingressで振り分け
  k8sはプレーンに

●ストラングラーパターン
・Strangler Facade
  レガシーとモダンを振り分け、隠蔽
・徐々にモダンに

●移行アプローチ
・機能分離してデータベース分離
・バッチ処理スケーラビリティUP
  顧客が増えていく中で同じバッチ処理ではスケールしない
・アプリケーションのステートレス化
  やがてコンテナに

●機能分離してデータベース分離
・でもドメインをまたいでjoin, join, join
・キーポイント
  効果の高いところに注力
  切り離すドメイン定義を慎重に
    ビジネス次第。正解はない。
  場合によっては大胆に移行

●スケーラビリティアップ
・ばらして札束で叩けるように
・せっかくだから並走など、構成も考えよう
・対応
  HttpRequests / Messaging
  Springなので、BatchFramework
  ステートレスAPサーバ
    State = インスタンス固有
    セッション、ストレージ、設定ファイルなど
・キーポイント
  stateはスケールを阻害
  新規はstatelessに
  既存アプリのstateを排除

●具体的な技術要素
・OpenAPI
・SpringBoot
・AKS
・Azure API Management

●複数クライアントライブラリ
・Swagger Codegen
  Controller Interface
  他のマイクロサービスのClient
  既存Client
  他にも
    Client for BFF
    Client for FrontEnd
-> OpenAPI便利!

●分散トレーシング
・k8sだとクラスタ、node、pod、appのログを横断的にでてくる
・見えないと辛い
・ログ収集、集積、解析
  いろいろあるがPapertrailを使っている
  推してはいない
・PagerDutyでアラート

●SpringCloudSleuth
・ID
  trace id: 相関ID
  span id : app内ID
・HttpHeaderでIDが伝播
・spring-cloud-starte-sleuthの依存追加だけ

●既存clientからも呼ばれる
・swagger codegenで、HttpHeaderを書くようにカスタマイズ
  既存にはDIコンテナがないのでFactoryでつないでいる
  RequestMappingからロギングするAOP
    Swagger生成分のannotationを判定

●TraceIDはどこまで有効か?
・TheadLocalにいる
  @Async, @Scheduledだとspringがうまいことやってくれる
  他ならLazyTraceExecutorで
・Istioに強い人募集中です!w

●設定ファイル集約
・SpringCloudConfigServerの ** がOpenAPIで書けない
・** を path variableとして扱ってみた
・ingress-Controller でデコードしていた

●k8sクラスタ移行
・新クラスタを立てて
・並行稼動で確認してすすめる
・環境追加、並行稼動を楽にしたい!
  Github + Circle CI + KustomizeでGitOps
  manifestのリポジトリ構成に合わせて環境を追加
  -> Azure API Management で切り替え


■マイクロサービス:4つの分割アプローチの比較

増田 亨 さん

●今日話すこと
・普段はやってきたことを話している。
・今回は実証されたパターンではない
・模索の現時点のスナップショット
  やったこと、やってないことをきれいに切り分けはできない

●マイクロサービスを実現する技術は揃ってきた
・クラウド、コンテナ、設計スキル
  必要条件であって十分条件ではない
・設計スキルに注力
  ソフトウェアをどう分割して拡張性をもたせるか

●マイクロサービスの動機
・ロードバランサで分散
  負荷分散
  リスク分散
  データ分散
・異なるサービスの連携
  機能分散

●基本のアプローチ
・枯れた技術しか使いたくないスタンス
・モノリスをつくって
・マイクロサービスの可能性を検討
  ばらばらにするのではなく
  部分適応を検討
・マイクロサービスへ移行を検討
  ある意味保守的

●設計スキルの基本は変わらない
・関心の分離
・工業集・疎結合
・モジュール化
->モノリスでもマイクロサービスでも活かせる

●サービスの模式図
・モノリスでも、1つのマイクロサービスでも同じ
  インバウンドがあってアウトバウンドがある
  データソースを経由してDBや他のサービスから取得
・マイクロサービスで、非同期に対する考え方を使うようになった
  非同期は、昔からあった、使い込まれてきた技術
  クラウドのmessagingサービスでやりやすくはなっている

●マイクロサービスをどこまで小さくできるか?
・理論的にはmethod単位
  RMI、CORBAなど昔、本気で検討されていた
  最小はmethod
・現実問題は、クラウド/コンテナ/設計/運用の習熟度による
  経験を積みながら分割していけば、更に細かくできる
  チームメンバーの入れ替えなども踏まえながら

●マイクロサービスをどこまで小さくするか?
・論理的なモジュール分割
  積極的に!大胆に!
  モノリスだからこそビジネスの観点は細かく分けられる
  マイクロサービスでは木にすることが多いので難しくなる
・物理的なモジュール分割
  慎重に!
  分散コンピューティングの8つの勘違い
    大昔に検討されたもの

●分散コンピューティングの8つの勘違い
・ネットワークは
  必ず落ちる
  遅い
  帯域は有限
  セキュリティホールになり得る
  誰かが勝手に変更する
  複数人がバラバラに管理
  転送はお金がかかる
  同じプロトコルでも、扱いはそれぞれ
・この世界に踏み込むのはハードルが高い!
  自分たちのスキル次第
  設計的には考えるべき
  -> 障壁が減ってくるはず

●4つのアプローチ
・ビジネスファンクション
・動詞/ユースケース
・名詞/リソース
・境界づけられたコンテキスト/サブドメイン
-> これらの組み合わせ

●ビジネスファンクションによる分割
・販売プロセスを21に分割
  これくらいの数にはなる
・分割したプロセスはつながっている
  人がつないでいるが、固定化したロジックで繋げられるかは分からない
・大企業の場合
  業務機能で部門が分かれてサイロ化
・中小企業の場合
  機能は分けられるが
  人が少ないから兼任している
  -> 人が認識している単位で分けるのが正しいのか?問題
・組織の構造も検討要素
  人のプロセスに合わせて分割できるが
  逆方向への連携が必要になったときが課題になる

●動詞/ユースケースで分割
・機能要求、開発範囲として分割しやすい
・トランザクション単位のマイクロサービスになってしまう
  サービス間でロジックの重複、断片化が起きやすい
  分岐の条件などドメインのロジックが、分断してしまう
  バッチ処理も起きやすい
・改善策: 薄いユースケースサービス
  ロジックを領域ごとに分割、整理
  重複や断片化をなくす
  これを複数のユースケースサービスが呼び出す

●名詞/リソースで分割
・エンティティのリソース
  識別番号の世界
・異なる関心事が混在して肥大化
  はじめは小さかった顧客が
  やがて数百項目に
・外部キー制約ができない世界になる
  モノリスでの捉え方が逆なのかもしれない
  本来は同じIDでも分けるべきなのかも

●境界づけられたコンテキスト/サブドメインで分割
・わからん!
  エヴァンス流
    コンテキスト/モデル/サブドメイン
  バーノン流
    ドメイン/サブドメイン/コンテキスト
  -> エヴァンス流で考えます!
・エヴァンス流の定義
  境界づけられたコンテキスト
    チームのコミュニケーションの範囲
    ソースやDBスキーマなど
  サブドメインでも分割できるが、危険
・一つのコンテキストに一つのモデル が目標
  モデルを一つに維持するか
  コンテキストを分割するか
  どっちに倒すかを検討していく
・モデル
  時間がないので、割り切って
  ビジネスルールのこと
・ビジネスのルール、ポリシーで分割していくのは有効なアプローチ

●トランザクションの分解
※時間がないので言葉だけ持ち帰ってくださいw
・モノリスで当たり前だったトランザクションの単位は大きすぎる
  間違ってはいない
  細かく分けることで、別の作り方が出来るのではないか?
  のアプローチ
・パイプライン化
  VETROでトランザクションを分解
・コーディネータ
  Sagaの考え方
  小さく分けて、ダメだった場合どうするか
・状態変化を非同期化


■感想

やっぱりJJUGの懐の深さはすごいですね!今回はアーキテクチャによせてセッションを聞かせていただいたのですが、たくさん「なるほど!」をもらえました。

去年2回参加させていただいたときは、E+F部屋が満席になったときはwimaxもテザリングもつながらないセッションがありましたが、今回はwifiのおかげでE+F, G+H部屋どちらが満席のときもスムーズな接続でした!

登壇者の皆さん、運営の皆さん ありがとうございました!


この記事が参加している募集

いつも応援していただいている皆さん支えられています。