関連図

いきなり完成した関連図です。

背景

以下は，この関連図をつくるに至った背景です。

アラサーエンジニアならば，様々な技術的キーワードに助けられたり振り回されたりしながらも，知ってて良かったなと思うものもあることでしょう。
私が良かったと感じているのは，関連図にもある以下のキーワードたちです。

ドメイン駆動設計
SOLIDの原則
ヘキサゴナル／オニオン／クリーンアーキテクチャ
DI（依存性注入）
テスト技法

上記のキーワードたちのそれぞれにフォーカスした個別のブログ記事などは探せばたくさんあるし，関係性に言及しているものも何度か見かけたことはあるが，一枚絵として見られるようなものはないかなと探したが見つからなかった。

めんどくさがりで下手くそだけど，なければ作ればいいということで作ってみました。
もっとしっかり書いてくれる人がいたら書いてほしい。。

各技術トピックに関するおすすめ書籍

各トピックでおすすめする書籍を紹介します。

ドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計 (Amazonへのリンク)

この本の見どころ

はっきりいって本が難しすぎて全部はわかりません。
個人的に役に立つかなと思ったところは

業務の複雑さに対応するため，業務のエキスパートを巻き込んで設計をしましょう。（ドメインエキスパート）
業務エキスパートと開発者との間でしっかり用語定義をして，認識に齟齬がないようにしましょう。（ユビキタス言語）
ID／ライフサイクルをもつEntityと不変のValueObjectという考え方。（Entity / ValueObject）
モデリングを頑張りましょう。

特に Entity / ValueObject についてはヘキサゴナル／オニオン／クリーンアーキテクチャのいずれでも登場するほどプラクティスとして扱われているのでいいものなんだと思います。
確かに Entity / ValueObject クラスがいい感じだと重複がなく，凝集性も高く，堅牢な感じになる気がします。

SOLIDの原則

Adaptive Code ～ C#実践開発手法第2版 (Amazonへのリンク)

この本の見どころ

C#ですがけっこういい本です。
良かった点としては

SOLIDの原則を実装を交えて紹介している。
SOLIDの各原則と親和性の高いデザインパターンを実装を交えて紹介している。
けっこうよく見かける実装をアンチパターンとしてぶった切っちゃう。
「コードの臭い」がところどころで紹介されている。
最後にアジャイルのコントみたいなのがあっておもろい。

Clean Code ～アジャイルソフトウェア達人の技 (アスキードワンゴ) (Amazonへのリンク)

SOLIDってわけではないですがきれいなコードを書くために読んでください。

ヘキサゴナル／オニオン／クリーンアーキテクチャ

Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) (Amazonへのリンク)

この本の見どころ

アーキテクチャという抽象的な題材に対してかなり具象的な見解が書かれている。
見所としては

低コストで高生産性を求めるのがアーキテクトだと言っている。シンプル。
アーキテクトにとってオブジェクト指向とは，ソースコードの依存関係を絶対的に制御する能力である．とかカッコいいことを言ってくれる。
依存関係をコントロールすることで，プロジェクト構成や外部ライブラリとうまく付き合う方法が提示されている。

実際クリーンアーキテクチャ読んでからは無駄にプロジェクト構成で悩むことはなくなったなぁ。

DI（依存性注入）

これもクリーンアーキテクチャを読めばいいです。
現場に入るとフレームワークを使うことが先行して，その素晴らしさに気付けないパターンが多いと思います。DIは使うことよりも，他の技術を実現するための実装のひとつとして捉えられてほしい。DIに使われている感じのプロジェクトもけっこうあると思う。

テスト技法

テスト駆動開発 (Amazonへのリンク)

この本の見どころ

テストというものの価値を見直す良い機会になる。

プロダクトコードとテストコードの距離を近くに感じられるようになる。
テストを書くこと／実行することによって実装を導いていく習慣がつく。
実装を導くペースを調整できるようになる（仮実装や明白な実装という言葉の違いを認識することで，テストに取り憑かれて開発のペースを落とす必要はないことがわかる）。
TODOリストを作って目的や思考のログを残しておく習慣がつく。
テストが常に隣にいてくれることで安心できる感覚がわかる。

習得ロードマップ

出会うタイミングは人それぞれであり，各々のコンテキストもあるが，ここでは個人的におすすめする順序を提示しておきます。

テスト技法（心理的安全性の確保／テストの習慣化）
ドメイン駆動設計（コア概念のモデリング）
SOLIDの原則（保守性の高いコード）
アーキテクチャ（プロジェクト構成に迷わなくなる）
DI（上記4つを実現するための重要な技術であることを噛みしめる）

どれも完璧に理解／実行するというのは難しいでしょう。
その時々に大切だと思ったことを理解しながら何周かするとすべてが少しずつ結びついてくるような気がします。
所属しているプロジェクトが恵まれていれば，普通に感じたり，当たり前に感じることも多いかもしれません。