今日も平常運転

楽しい人生を諦めないためのブログ

オブジェクト指向をとりまく開発手法/技法/アーキテクチャの関連図と習得ロードマップ

関連図


f:id:code365:20200619233038p:plain


背景

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


  • ドメイン駆動設計(Domain-driven design, DDD)
  • SOLIDの原則
  • ヘキサゴナル/オニオン/クリーンアーキテクチャ
  • DI(依存性注入)
  • テスト技法


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


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

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


ドメイン駆動設計

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

エリック・エヴァンスのドメイン駆動設計【電子書籍】[ エリック・エヴァンス ]

この本の見どころ

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


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


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



SOLIDの原則

Adaptive Code ~ C#実践開発手法 第2版

Adaptive Code ~ C#実践開発手法 第2版【電子書籍】[ Gary McLean Hall ]

この本の見どころ

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


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


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

Clean Code アジャイルソフトウェア達人の技【電子書籍】[ Robert C.Martin ]

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



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

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

Clean Architecture 達人に学ぶソフトウェアの構造と設計【電子書籍】[ Robert C.Martin ]

この本の見どころ

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


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

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



DI(依存性注入)

これもクリーンアーキテクチャを読めばいいです。
現場に入るとフレームワークを使うことが先行して、その素晴らしさに気付けない人が多いと思います。DIは他の技術を実現するための実装のひとつとして捉えてほしい。



テスト技法

テスト駆動開発

テスト駆動開発 [ Kent Beck ]

この本の見どころ

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


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



習得ロードマップ

出会うタイミングは人それぞれであり、各々のコンテキストもあるが、ここでは個人的におすすめする順序を提示しておきます。
それぞれが難しいので、概念から少しずつ理解して、反復していく順序と思ってください。


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


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