進化的アーキテクチャ - 読書会 第8回
https://gyazo.com/c683784d06cbd3dbf75d03f7f6a52ed3
日時： 2021/3/31 (水) 20:30 - 22:00
対象： 5章 進化的データ
5.1 進化的なデータベース設計 〜 5.3 ケーススタディの終わりまで
ページ：103-118
参加者 ：
イベント：
Zoom ：
司会 ：tfujita.icon
20:30-20:40 10 min 近況
20:40-21:50 読書会わいわい（司会のかた自由にデザインしてくださいね）
21:50-22:00 ふりかえり
はじめに
気になったコメントには、顔アイコン(ショートカット: Ctrl + i)で教えてください。
kobatomo.icon*5とか書けばkobatomo.icon*5複数表示されて興味津々具合がわかりますよー。
できる限り自分のログは自分で残して、みんなでログを作り上げましょう。
近況
tfujita.icon：藤田です。香川県から参加してます。医療系のソフトウェア開発やってます。今日は息子の幼稚園がお休みなので高知の海洋堂に行ってきました＾＾
羽飼です。名古屋と長野に住んでいます。フリーランスです。ソフトウェアの開発やっています。今は食品メーカーの販売管理システムの刷新に関わっています。
5章 進化的データ
5.1 進化的なデータベース設計 p.103-106
tfujita.icon：
データベース・リファクタリング知りませんでした！
P.104 コードとともにスキーマを進化させることにある
確かに、確かに。データベースのバージョン管理できたらなあと最近気になってます。
UNDOつかわないですねー。戻すという目的でもバージョン進めてその「戻す」をする。
意外とバージョンを合わせるのはミスしてしまうことがある。すぐには気付くのだけど。。
そのマッピングがスキーマと同期していることを保証するため、適応度関数の追加を検討する必要がある
どんな適応度関数だろう、少しピンとこなかった。
5.1.2 共有データベース統合 p.106-111
107 しかし、データベースを統合点として使用すると、アーキテクトは全ての共有プロジェクトを横断するデータベーススキーマが化石化してしまうことをすぐに発見する
考えただけでゾッとする。。
結合しているアプリケーションの１つがスキーマの変更によって進化しなくてはならない場合はどうだろうか。
今やっている、マルチテナントアプリケーションのケースに近いと思った。データベース分離型でやっているけど、スキーマの変更にはいつも気を使う。。
5.2 不適切なデータ結合 p.111-115
113 開発者は、重厚なトランザクションシステムを、不適合なアーキテクチャパターン、例えばマイクロサービスのような疎結合を強いるものに移行しようとすると
この管理は、難しそうだなあといつも気になる部分です。
サービスに対するロールバックと、DBのロールバックを同じにするのは諦める、一旦コミットする。それを取り消すメソッドを用意して実行するケースが多い。
5.2.2 データの年齢と質 p.115-118
115 アプリケーションはどうせ短命だからそこまで気にしない。しかし、うちのデータベーススキーマは貴重だ、何しろ永遠に生き続けるものなのだから
ここまでは言い過ぎな気もするけど、自分もこう思ってしまいがちかも＾＾；
スキーマを見直して再構築していくことを滅多にしないDBAは、・・・
今、この化石に悩まされ中・・・。非正規化しようか悩んでます＾＾；
『データベースリファクタリング』は、たしかにコードのリファクタリングほど浸透していないし、気軽に行われないですね。データーベースの神格化が足枷になった経験は何度もあるので、こういう啓蒙は必要。
DBAのジレンマ。
COBOLで１件１件のマスタ読み込み。それをRDBでやると遅くなる。DBAの視点からすると、ちゃんとRDBの特性わかってよと思ってただろうな。DBA vs アーキテクト。主張する人のやりたいことあるので、お互いの意見聞きながらできるといいが、簡単ではないな
今日のふりかえり
tfujita.icon自分が、今やってるところに近かったので試したい思いました。
羽飼：「データベースリファクタリング」を浸透させよう。
役に立つ(?)リンク
次回
日時： 2021/4/14 (水) 20:30 - 22:00
対象： 6章
ページ：119-126
役割分担
司会：
ページ作成：
connpass：
読書会ベロシティ
103-118, 15 ページ