🐡

現場から学ぶシステム設計：座談会

2021/11/16に公開

システム設計

概要

2021/10/27に開催された下記勉強会のメモです

セッション

各社紹介

Alp, Inc.

サプスクリプションビジネスのインフラ
- 契約の情報、請求などのSaaS
言語：scala

LegalForce

契約リスクを制御する製品
言語：ruby

Showcase Gig

次世代店舗抄出プラットフォームの提供
- 店内でオーダー、テイクアウトのアプリなど
言語：go

3ヶ月前の悩みと振り返り

LegalForce

肥大化するユースケース
Mixinを使った手続きの共通化 -> テストが肥大化した
永続化層とドメインオブジェクトの切り離しできていなかった -> 値オブジェクトの導入
- 実装が楽しくなった
- Mixinを使った共通化より粒度が細かいので再利用価値がました
増田さんコメント
- 値オブジェクトやコレクションオブジェクトの考え方を取り入れてデータベース操作から分離する。
  その結果、ドメインロジックの整理の次のステップが見えるようになる。
  永続化とドメインロジックの分離が第一歩だし、そこを超えることができると、まったく違う世界が広がる。

Alp, Inc.

Scalebase Connect for Saleseforce(SFA)の開発
技術セットが大きくなる
採用難しい
コアシステムのドメインを流用した実装が負債化
増田さんコメント
- 外部との接続に伴う変換はドメインモデルパターンの大きな課題。
  たいへんだけど、そこにひと手間かけることで、全体としては見通しがよくなる。

Showcase Gig

整合性が大事なのか？
- 機能的に使えていれば良い
- 解消すべき不整合が解消できれば問題ない
実践したこと
- 不整合に気づけること
  - 失敗時のアラート
- 不整合が起きるケースの洗い出し
- 不整合を解消できること
増田さんコメント
- どこに注力するか。
  不整合を徹底的に防止するように頑張るか？
  不整合が起きる前提で、不整合の発生の検知と対処方法の提供のほうに力点をおくか？

最近の悩み

LegalForce

サーバー間トランザクション制御
- 複数サービスでユーザ作成してどこかで失敗、ロールバック途中でさらに失敗したら？->不整合
- リトライで発生率を下げられるはず
- 分散トランザクションは選びたくない選択肢
- ロールバックしない選択肢も
  - 放置して後でやるとか（時間差）
- 今ロールバックが必要？
- 不整合ありきでオペレーションをどううまくやるかで考えた方がいいのかも？
- 分散トランザクションでロールバック頑張るは頑張るの方向性としてどうなのか？
増田さんコメント
- まずはロールバックしなくていいのでは？(→リトライへ)
  即時の整合性いる？(→後回し)

↓こういう記事もあるようです

Showcase Gig

境界づけられたコンテキストの2つをまたいで共通なもの。共通化するか？
- 共通化の罠
- 重複上等というアプローチもあり
- コンテキストの切り方を変える、もあり？

↓前に話題になったやつ

ミノ駆動さんコメント
- DRY原則は「概念の重複を許すな」を意図しており、同じようなロジックでも実は別概念だった、ということがよくある。こうしたロジックを共通化すると後で苦しむことになる。別概念かどうか識別するには、使用目的が同じかどうかがひとつの観点。
増田さんコメント
- モジュール分割の視点を変える
  - 関心の分離ができていることが重要で、重複の排除はちょっと違う
- 今後事業展開していくことを考えて分割すると良い
  - 判断材料として大きい
  - 事業方針に沿ったモジュール分割を考えたほうがいい
- モジュールを正しく分割するのは難しい、これは現実。それをやるのが設計

Alp, Inc.

モジュラモノリスをマイクロサービス化でどのような恩恵が？
- 契約のところは重量なのでいかにわかりやすく分けられるか
- 契約はコアの関心事。ビジネスでも重要。
- ここはもっともっとわかりやすく壊れないものを作るべき
リファクタリングをつづきていったらマイクロサービスに切り出される
- なんどもなんどもわけて疎結合が進んだら、マイクロサービスに切り出せる
「リファクタリングを繰り返して、「ここは分けて良い」という手応えが出たところをマイクロサービスとして切り出す。」

意見交換

モジュールの分割がうまくいったという基準は？
- あるんですかね？そんなものは。
- ダメなのはわかる。ダメなのをキレイにしていくを繰り返す

Discussion