読者です 読者をやめる 読者になる 読者になる

DDDにおけるアプリケーション、ドメイン、インフラの変数名について

大したことじゃないんだけど、
コードを書いてて
「レイヤによって変数名の命名ルームを変えるべきでは?」
と思いました。

アプリケーションレイヤ、ドメインレイヤは
ユビキタス言語に近い形で命名するのがいいと思う。

ユーザーID であれば userId
ルームID であれば roomId


でも、インフラレイヤはDBやmemcacheが操作対象になるので、
ある程度そのような対象に引っ張られた変数名の方が可読性が上がる気がする。

アプリケーションレイヤ、ドメインレイヤでは userId だった変数名も
DBのテーブルのカラム名が id であれば、
id という変数名にした方が良いのかもしれない。

具体的にユーザーIDベースでDBからユーザー情報を取得する実装を考えてみる。

まずはアプリケーションレイヤ。
$userId というのが(当然ながら)ユーザーIDを表している。

<?php
class Application {

	public function hoge($userId){
		return UserRepository::getByUserId($userId);
	}
}

次にドメインレイヤのリポジトリ
getByUserId() の引数は $userId のまま。

<?php
interface UserRepository {
	public function getByUserId($userId);
}

次にインフラレイヤ。
このレイヤでは getByUserId() の引数名を $userId から $id にしている。
これはDBのカラム名が id だから。

<?php
class UserDao implements UserRepository {
	
	public function getByUserId($id){
		$sql = "select * from user where id = ".$id;
		return Db::query($sql);
	}
}

インフラレイヤの変数名がドメインレイヤの変数名に引っ張られると
ドメインの流出になってしまい、
インフラレイヤの本来の責務(実装)に影響を与える可能性があるかもしれないので、
やはり変数名は変えた方がいいと思う。

ちなみに、この考えに至る前はDBのカラム名ユビキタス言語由来の単語を特に考えずにコードを書いていたので、
命名ルールはグチャグチャでした・・・。
DBのカラム名に統一していたわけではなく・・・。
ユビキタス言語を踏襲するわけでもなく・・・。
ハイブリッドでした・・・。

こーゆーのは本を読んだだけだと分からないから、
コードを書くって大事だと思いました。