スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
このような要求があった場合、一般的なエンジニアはメールアドレスと電話番号を持つクラスを定義し、どちらもオプショナルな値（必須ではない）にするような設計をするかと思います。そして、作成時・追加時・編集時にどちらもなければエラーにするというバリデーションを実装することでしょう。つまり、要求をそのままに実装に落としていくという意味です。要求自体はかなり具体的に書いてありますから、そのまま実装に落とすこと自体が悪いとは言い難いでしょう。 一方、なぜメールアドレスと電話番号の2つを利用アカウントが持っているのかという「意図」をよりはっきりと記述してもらった次のような要求を見てみましょう。 要求を発する側の意図としては、ただ単にメールアドレスや電話番号が独立して欲しいと考えていたのではなくて、利用アカウントごとに1つは「連絡先」が欲しい。ひいては、何らかの手段で連絡できるといいなと考えていたことがわか
役割駆動設計で巨大クラスを爆殺する - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、ドメイン駆動設計を基本思想とする「役割駆動設計」を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 小さくシンプルな構造に落とし込み、堅牢で変更容易性の高い設計へ昇華させる。 例１：筆者をモデリング 分かりやすくなるよう、まず私を例にモデリングしてみます。私は以下のような特徴があります。 IT企業
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
