私はウンザリしています。 「○○対応」は曖昧なのでやめてください。「○○を修正した」の方が直接的です。 こんな指摘を新人が入ってくるたびにコードレビューやドキュメントレビューで繰り返しています。どうも、プログラマー（と言うか理系？）には独特の言語文化があり、みんな同じような分かりにくい表現をしてしまうようです。 「レビューを依頼する前にこれを読んどいて！」と言える記事なり本なりがあれば良かったのですが、良いものが見つけられなかった（ご存知なら教えてください）ので、とりあえずレビューでよく指摘する日本語の文章の問題点や変な表現ポイントを列挙しました。 なお「コメントは必要十分な量を書く」「チケット番号やWikiのURLを書く」といった、良く知られた・日本語に限定されない話題は省略しています。 （※コメント欄などの指摘を受け「補足」を追加） （※タイトル変更。「コードレビュー前に直して欲しい日

DDDの文脈の中で、 「ドメイン知識とユースケース(≒アプリケーションの知識)は何が違うのか？」 という疑問がよく持たれます。 この記事ではその違いを説明し、DDDのコードにどう反映するかを書きます。 あるToDoアプリの仕様 事例として、ToDoアプリの話をします。 「仕様を決める」と言ったとき、以下のように箇条書きで決めることがあると思います。(Jiraのようなチケット管理システムのチケット詳細として書いたりしますよね) ユーザー登録、非活性化ができる メールアドレスは重複登録できない タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる タスクは3回までしか延期ができない 非活性化されていないユーザーにアサインができる タスクを完了、アサインするとタスクレポートが作成される これはいわゆる「ビジネスロジック」と呼ばれて、3層レイヤーのアーキテクチャではBusine