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 で切り替え
■マイクロサービス：４つの分割アプローチの比較
増田 亨 さん
●今日話すこと
・普段はやってきたことを話している。
・今回は実証されたパターンではない
・模索の現時点のスナップショット
やったこと、やってないことをきれいに切り分けはできない
●マイクロサービスを実現する技術は揃ってきた
・クラウド、コンテナ、設計スキル
必要条件であって十分条件ではない
・設計スキルに注力
ソフトウェアをどう分割して拡張性をもたせるか
●マイクロサービスの動機
・ロードバランサで分散
負荷分散
リスク分散
データ分散
・異なるサービスの連携
機能分散
●基本のアプローチ
・枯れた技術しか使いたくないスタンス
・モノリスをつくって
・マイクロサービスの可能性を検討
ばらばらにするのではなく
部分適応を検討
・マイクロサービスへ移行を検討
ある意味保守的
●設計スキルの基本は変わらない
・関心の分離
・工業集・疎結合
・モジュール化
->モノリスでもマイクロサービスでも活かせる
●サービスの模式図
・モノリスでも、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部屋どちらが満席のときもスムーズな接続でした！
登壇者の皆さん、運営の皆さん ありがとうございました！
この記事が参加している募集
いつも応援していただいている皆さん支えられています。