データベース中心の設計になってしまう問題と闘う - laiso

『手を動かしてわかるクリーンアーキテクチャ 』の第二章の冒頭に登場する話題に共感したので紹介。 従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 20p 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 作者:Tom Hombergs,須田 智之インプレスAmazon 著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が

[laiso]

読み返したら本文にUIって出てきてないじゃん・・　ああ、Interfaceを狭義で解釈する人がいたのか

[hdampty7]

クリーンアーキテクチャのことはよく知らんがデータベース中心の設計で正しいです。システム開発で長期間保持されるのがDBスキーマとデータだから。UIのためにDBスキーマを変えるなど本末転倒。

[takahashim]

DB中心だと開発運用が進んで要件が変わってくるにつれ、既存のDBに引きずられて適切な変更ができず全体の設計が歪む、というのがここで闘っている「保守性が低下」する問題かと／もっとも2回で済むかというと…

[ngmy]

POAとDOAとOOAのそれぞれが相手のことを良くないと言っているのに行き着く先は同じ結論（プロトタイプ実装）というのが面白いところ。我々は原理主義者になることなく、現実的に現実の問題と戦う必要がある。

[strawberryhunter]

その本は読んでいないので問題の背景がわからないが、UI設計に変更があったら、それは要件が変わったということなので、横着しないでDBを含めすべて修正したらいい。

[kabochatori]

アプリケーションはDB中心にならざるを得ないんだが、人間は画面から作らないと必要なデータを想像できない問題。

[xsde]

私も今日のシステム構築の色々な問題は "2回実装する" で解決すると思っていて、黎明期からそういう考え方が常識化していたらもっとITの現場は変わっていただろうと思う。

[otherworld]

DBが一番息が長いなんてとはなく容易にAPIに切り出されたりし得るし、これまで出会ってきた環境や経験次第では過剰と思う人もいるだろうけど、それらを念頭に入れて設計すると実際変更に強い。

[tockri]

UIのためにDBを変えるんじゃなくて、UIに現れるビジネスロジック（ドメイン知識）のためにDBを後づけで設計するのね。

[taiyow]

クリーンアーキテクチャではUIは1番外側のリングで(DBもだが)、そこへの依存をなくすことでドメインルールを保持するって話なのになんでDBとUI比較してる人おるん。1分調べたらわかることを「よく知らん」で済ますなよ。

[harumomo2006]

DBを変更するとロクなことが起きないのでDB設計を死守するのが最優先。どうしても変更なければならないのならUIで対応、可能なら人間が運用で何とかする

[hachibeechan]

二重の極みスゲーわかる。ところでこのDB中心設計についてはわりと諸説ありそうな部分だし議論のしがいがある部分だとおもう

[choota]

この話、ドメインモデルの整合性をユーザーと合意するためにプロトタイプ→本番と二段構えにするとスムーズっていう話よね。システム開発的で作り手側の視点でDBが優先って言ってる人は、ズレてる気がするな。

[syu-m-5151]

曳光弾によるアプローチが好き。その目的は、プロトタイピングが解決しようとする目的とは異なります。その目的とは、アプリケーション全体がどのように連携するかを知ることです。

[tacchini]

wow

[oisux]

toCで売っているものは大体DB設計ではなくUIなので、UIを中心に設計するのは理にかなっていると思う

[puhu208n]

両極論を言えば、売れる時はUIUX、逃げられる時は既存データや業務プロセスだから、詐欺的に売り抜けるならDBに割く工数は捨て金、逃げられない顧客のキープ目的ならフロントへの工数は捨て金だろ。そんだけじゃね。

[tettekete37564]

DB中心の設計自体は正しい。ちゃんと正規化されているならば。クリーンアーキテクチャ的には DB は一番外側になるので、そこでの密結合は問題では無いだろう。

[evamatisse]

ここまで来るとRDBMSを使わない方がいいんじゃないか？

[NetPenguin]

ドメインのエンティティを設計し、DBのスキーマも設計し、それぞれの辻褄があうように何回かいったりきたりして整えていくので、実際には相互に依存してしまうと思っている。その上でドメインのエンティティが

[rryu]

DB中心に設計した時に抜けるのは要件的には不要だが人間がそれを行うにあたっては無いと困る情報で、そういうのは最後の方に判明するので一回やってみるというのが有効になる。

[yamadadadada2]

話の深さ広さ（と、時間的なスパン）が曖昧すぎてこれだけだとなんとも言えないなと。「作ってから変更」が良くはまったのか、「単に設計力が足りない」だったのか

[cpw]

DBをベースに開発すると決めたらDBに依存するのは当然。逆に依存させないようにするとDBの機能を使いこなすことができず保守性の低いコードが生まれる。DB移行のリスクを予め組み込むのはやり過ぎ。

[ryouchi]

必要なのはデータであってI/Fではない。データをうまく格納する手段としてのI/F設計でありやはりデータベース中心の設計でいいような気がする。

[silly_billy]

インフラストラクチャー層とアプリケーション層はお互いに疎結合な方がいいですよね。良い状態を維持するにはリファクタリングしかないと思ってるけど、現場によっては難しいことも多い

[gabill]

わかる。2回作りたい。あいだを置かず2回つくりたい。

[chiroruxx]

人月の神話でも2回実装しろって言ってたな。

[umai_bow]

ドメイン・データストア間のインターフェイスが吸収するべきというのは分かるんだけど、じゃあそのデータストアはどう設計すればいいのか？（無限の表現力を求めることにならないのか？）というのが

[pmint]

クリーンアーキテクチャ系の本を読んで採用しなかった話。正しい。/ クリーンアーキテクチャ本は意識高い系が単に知名度のために書いた本でしょ。「クリーンアーキテクチャは実現できない」としてる点は正しいけど。

[nmcli]

自分が恵まれてるのか、自分がこの対処法を得意としてるのか定かではないが、いままで設計はデータベース中心だった。わし古風なやり方してるのかもしれないな。

[snowcrush]

データモデルを設計の中心に置くべき。そうなっていないアーキテクチャはいずれ負債になるので避けるべし / 最初から正しく設計するのが難しいので再設計するフェーズをおくことが重要なのはその通りだと思う

[yasushicohi]

「2回実装する」

[versatile]

db のための entity. それをまとめる repository. db にいれるための DTO. 物理 column のための mapper. そして最悪な SQL. db との I/F 的な model. そしてトランザクション！ db がないと超楽。db が開発に時間がかかる要因なのだ！

[ch1248]

2回実装、なるほど。書籍の方に興味が出た。

[kobito19]

どこにUIに依存させろとか書いてんねん。脊髄反射すな

[s-nanagi]

改めて設計し直すからDBファーストではないという主張？論点がちょっとわかりにくいかも。永続化層とドメイン層の疎結合化と依存方向の決定こそが重要なのであって、手順は別の話題という気がする。