はじめに
上司に「部署で一番設計に詳しくなりなさい」と言われたあの日。
設計に詳しいエンジニア、かっこいい。なんかモテそう。年収も上がりそう。
クリーンアーキテクチャ本を読破した私が "リーナス・トーバルズが言ってそうなこと" を言ってる姿が浮かびました。
現実は、3ページ目で「明日読もう」と本を閉じる自分でした。まだ明日は来ていません。
でも、完全に無駄だったわけじゃありません。難しい本は読めなくても、基礎的な本を読んだり、日々のレビューを噛み砕く中で、自分の中に変化が起きていました。
正解かどうかはわかりません。でも事実として起きた変化を書きます。
変化①：読む順番を意識するようになった
いきなりクリーンアーキテクチャ本を読むのは、九九を知らない小学生が微分積分の教科書を開くようなもの。そりゃ何言ってるかわからない。
調べ直した結果、こんな順番が良さそうだとわかりました。
| ステップ | 学ぶこと | おすすめ書籍 |
|---|---|---|
| 1 | 良いコードの書き方の基礎 | 「リーダブルコード」「良いコード/悪いコードで学ぶ設計入門」 |
| 2 | DDDの考え方の入門 | 「ドメイン駆動設計入門（成瀬本）」 |
| 3 | アーキテクチャの全体像 | 「クリーンアーキテクチャ」「エリック・エヴァンスのDDD本」 |
自分は今、ステップ1を読み進めているところです。
変化②：型で守ることを意識するようになった
もう一つ意識するようになったのは、値を型で守るということです。
例えばメールアドレス。stringのまま扱っていると、不正な値が紛れ込んでも気づかない。使う側で毎回バリデーションするのも漏れが起きやすい。
これをValueObjectで包むと、不正な値がそもそも存在できなくなります。
class Email {
private function __construct(
private readonly string $value
) {}
public static function create(string $value): self {
if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {
throw new InvalidArgumentException('無効なメールアドレス');
}
return new self($value);
}
public function getValue(): string {
return $this->value;
}
}
function registerUser(Email $email) {
// Email型が来た時点でバリデーション済み
}
特にビジネス的に壊れてはいけない箇所にはこうやって堅く守る。ただし、重要でない箇所まで過度に抽象化するとかえって複雑になるので、どこを守るか見極めるのも大事だと思っています。
さいごに
ここに書いたことが正解かはわかりません。でも、難しい本が読めなくても、日々の積み重ねで変化は起きる。
次は、コードを書く前に設計段階で相談する動きも意識していきたいです。
まだモテてはいないけど、変化は起きている。
同じように「設計勉強しなきゃ」と思っている方の参考になれば嬉しいです。