【書評】現場で役立つシステム設計の原則はオブジェクト指向の入門によさげな本だった

Amazonを徘徊していたところ、面白そうな本を見つけました。

作者:増田亨
技術評論社

目次を見ると、オブジェクト指向の考えとドメイン駆動設計(DDD)を組み合わせて、変更に柔軟に耐えうるコード設計をどのように実現するかを教えてくれる本のようです。社内の輪読会でドメイン駆動設計(DDD)を扱ったのですが、どのようにコードで表現するかがイマイチよく分からなかったので、買って読んでみることにしました(いつもの衝動買い...😂)。

こちらの書籍の購入を検討している方、どのような方にオススメできるのかを書評という形でこちらの記事にまとめたいと思います。

オススメできる人

オブジェクト指向について1ミリも知らない人
ドメイン駆動開発(DDD)について興味がある人
設計についての本を初めて読む人
難しい説明よりもサンプルやコードを見て理解したい人

オススメできない人

オブジェクト指向、ドメイン駆動開発(DDD)についてそこそこ詳しい人
設計の本をすでに何冊か読んだことがある人
オブジェクト指向の知識をさらに深めたい人

がっつりオブジェクト指向の本ではない？

読了したまず思ったことですが、サブタイトルに「変更を楽で安全にするオブジェクト思考の実践技法」とあるのでオブジェクト指向にめっちゃフォーカスを当てた本という印象だったのですが、そういうわけではありませんでした。「オブジェクト指向とは...こういったものである」といった定義や説明の話はなく、実際のコードと例を元にデータとロジックをひとまとまりにする(カプセル化)こと、凝縮度を高めることの重要性について述べられています。

扱うテーマ(抜粋)

データとロジックを分離しないことの何が問題なのか
なぜ重複したコードが各所に現れるのか
制約やルールをドメインオブジェクトに隠蔽する
ドメインへの理解を深めること
変化に向き合うことの重要性
オブジェクト指向の学び方

今になって思えば、データとロジックをひとまとめにすること(カプセル化)がオブジェクト指向の特徴の1つなので、オブジェクト指向にフォーカスした本であることは間違いないですね。

ドメインオブジェクトについて

本書で最も印象強く登場していたかなと思うのがドメインオブジェクトです。
ドメインオブジェクトとはドメイン駆動設計(DDD)に登場する単語で、ドメインを構成する一要素に特化したオブジェクトのことです。例えば、通販サイトというドメインにおいてユーザーが登録するユーザー名について考えてみます。

ユーザー名の制約

ユーザー名は必須項目
ユーザー名は3文字以上、10文字以下で設定可能
アルファベットのみ使用可能(a-z, A-Z)
記号はハイフン(-)とアンダーバー(_)のみ使用可能
同じユーザー名は登録出来ない

Rubyで書いてみると...

本書ではサンプルコードはJavaで記述されていますが、あえて普段書いているRubyを使って書いてみます。ユーザー名の制約をRailsとActiveRecordを使って普通に書くならばユーザーモデル(app/modesl/user.rb)にバリデーションのコードを書くことになるでしょう。

class User < ApplicationRecord
  validate :name_invalid?

  def name_invalid?
    # ここに条件を記述
  end
end

これでも十分なのですが、他画面・機能からユーザー名に関する情報を扱いたい時にコードが重複してしまう可能性があります。またユーザー名に関する制約がユーザーのモデルに定義されているのもおかしな話です。

ここでドメインオブジェクトの出番です。ユーザー名に関する制約はユーザー名を表現したクラスに定義します。

class UserName
  def initialize(name)
    # ここに条件を記述
    raise 'ユーザー名は3文字以上で登録してください' if name.size < 3
    raise 'ユーザー名は10文字以下で登録してください' if name.size > 10

    @name = name
  end
end

ドメインオブジェクトを活用することで、ユーザー名に関する制約をUserNameクラスに隠蔽することができました。このドメインオブジェクトを各所から使い回すことでユーザー名に関する制約や処理が、他のクラスに定義されることを防ぐことができます。

DB設計とドメイン設計は異なる

衝撃的だったのが、よくあるDB設計(eg: ER図を書いたり...)とドメイン設計は全く別の設計として考える必要があるという話です。いつものノリでDB設計をしてからロジックを書いていくと、データは定義されているがロジックが定義されていない状態、つまりデータとロジックにまとまりがない状態が発生しやすくなるそうです。

ドメイン設計では実現したいストーリを元にデータとロジックを設計するという話には、なるほどなぁと感じました。

なんでもオブジェクト指向なのは違うかも

後半になるにつれて開発の進め方や、設計の進め方の話になります。

ただ、個人的に後半の章の話には「そうなんか？」と納得できない部分がありました。開発の進め方の話では「従来の開発では要件や仕様を一通り定義してから開発を始めるのに対して、オブジェクト指向の開発では設計や分析をしながらコードも書く」と...ありますが、これは別にオブジェクト指向に限った話ではないです。

どちらかというとアジャイルやスクラムというテーマで扱うべき内容でしょう。

テーマが広い

DB(Chapter6)やWEB API(Chapter8)の話が登場しますが、割愛しても良かったかもしれません。
ページ量の関係かもあるでしょうが、浅く広くなってしまっている印象を受けました。これぐらいの情報は設計本を読む人だとご存知でしょうし、章を用意してまで書く必要があったとは思えません。

逆に言えば知識のない読者でも読み進められるようにという、著者の配慮かもしれません。

最後に

「現場で役立つシステム設計の原則」は非常に読みやすく300Pほどありますが、3日もかからず読めてしまいました。
「設計の書籍やオブジェクト指向について興味があるけど、いきなり難しい書籍はちょっと...」という方にはおすすめできる一冊です。くどい程、データとメソッドをひとまとまり(カプセル化)することの重要性について述べられています。

少しでも興味がある方は、サクッと読めるのでぜひ手に取って見てみてください。

現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法