-
- いいね！0
もう疲れちゃって 全然動けなくてェ...(💉x5)
@kamekoopa
削除フラグのすべてが悪いというわけではないんだろうけど「消すのがもったいないからつけてるだけ」とか「エンティティの状態遷移設計サボってる」とかのパターン多い気がするしそうやって付けられた削除フラグはデータの整合性簡単に崩すので、やはりきな臭さは感じる。
2014-05-07 16:24:12
すえなみ
@a_suenami
「削除」という言葉自体をなるべく使わないようにしてる。会員だったら「退会」だし、商品だったら「取扱い中止」だし、コンテンツ投稿だったら（ちょっと苦しいけど）「無効化」とか「非表示化」とかにする。なるべくドメインの言葉に近い言葉を選ぶ。
2014-05-07 16:29:36
すえなみ
@a_suenami
例えば「退会」がdeleteとかってメソッドで実装されてたり、deleted_atみたいなカラムで制御されてたりすると、ドメイン側やビジネス側の人と話すときに都度脳内で翻訳作業をしないといけないから結構つらいんですよね。
2014-05-07 16:37:36
すえなみ
@a_suenami
ちょっとシステムわかる人だと「退会は論理削除として実装されてますか？」みたいな質問してくるし、それは実装の詳細なので今は気にしなくていいですよぉぉ、むしろ「退会」という概念がどういうものなのかを考えましょうよぉぉぉ、ってなるんですよ。
2014-05-07 16:38:54
非実在naka aki
@naka_aki_spl
たしかに、「削除って何よ？」は明確にしないとダメっすね。無味無臭な「削除」って言葉(機能)が実装上に有ると、今度は業務のドレを削除機能に割り当てるべきか、割り当て「ない」べきか、でいちいち悩んだりブレたりモメたりする。
2014-05-07 16:40:07
非実在naka aki
@naka_aki_spl
なるほど。「ほげ情報というテーブル名がクソ」なのと同様に「削除というメソッドや削除フラグ／日時というカラム名はクソ」なのか！
2014-05-07 16:40:40
すえなみ
@a_suenami
@naka_aki_spl まあ、そうですね。詳細な実装は性能要件や運用要件の都合もありますが、JOINのコストがそれほどでもなければむしろ僕の場合は「会員退会」というテーブル作っちゃいますかね。そのほうがリソースとイベントの分離性が高いですし。
2014-05-07 16:42:44
すえなみ
@a_suenami
@PoohSunny そうですね。個人的には「元に戻す」という表現は好きではないですがその行為に適切に名前をつけられないことが多いっていうのは正直あります。それにのっける形で「間違って退会するケースなんてあるんですか？」「頻度はどれくらいあるのですか？」みたいに繋げますね。
2014-05-07 20:08:22
Yotaro TAKAHASHI
@PoohSunny
@a_suenami 確かに、元に戻すって表現は難しいですよねぇ。多分再入会とも違うだろうし、とはいえ『間違ってもなんとかなります？』とか聞かれたくもない気がします（笑） 論理削除の時に比べて、自然と相手と対話がつながりそうでよいですね！
2014-05-07 20:12:59
すえなみ
@a_suenami
@PoohSunny 「元に戻す」という行為は意味的なレベルが低いというか汎用的な表現すぎて仕様になりにくいんですよね。もし誤操作しやすいというだけであればUIの工夫でよいですし、そうではなく本当に意図的に退会したはずなのにそれを元に戻して欲しいケースがあるということはそこに（続
2014-05-07 20:41:54
すえなみ
@a_suenami
@PoohSunny 理由があるはずで、「論理削除ですか？」→「はい、そうです」というコミュニケーションしかやっていないとその理由に着目しにくいと思いますし、「論理削除」という本来実装技術であるはずのものが仕様の世界に漏れ出してシステムが複雑化することになると思うんですね。。
2014-05-07 20:43:10