3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめてのアドベントカレンダーAdvent Calendar 2024

Day 5

【読書感想文】現場で役立つシステム設計の原則

Last updated at Posted at 2024-11-10

この本を読もうと思ったきっかけ

きっかけは、ドメイン駆動設計について勉強したかったからです。
ドメイン駆動設計について調べると大体最初に出てくる説明が、「ソフトウェアで解決したい専門領域を、ソフトウェアの設計にそのまま反映させる」だと思います。
僕には、この説明が抽象的で理解できなかったので、書籍を購入して勉強しようと思い立ちました。

そのうえで本書を選んだ理由ですが、
本書のAmazonレビューで、「ドメイン駆動設計の基本が押さえられた」旨のレビューを多く見たので、購入に至りました。

あとは、単純にタイトルに惹かれました。笑

読む前の自分の知識レベル

実務経験は6年目です。
機能設計、詳細設計、実装、テスト(テストコード)等ある程度の開発プロセスは経験しています。

主に読んだことのある書籍は以下になります。
ある程度のシステム設計に関する原則・原理は理解しているつもりです。

また、ドメイン駆動設計に関する知識レベルですが、ざっとこんな感じです。

  • ドメイン駆動設計って何が良いの?
  • ドメインモデル?ユビキタス言語?ドメインサービス?専門用語はわかりません

ドメイン駆動設計の概念だけは知っていますが、
メリットや具体的な手法についてはわかっていませんでした。

読んだ感想

本書は10章までありますが、
ドメイン駆動設計について説明がある4, 5, 7, 9章 をメインで読んだ感想になります。
各章のざっくりとした内容は、Amazon商品ページに目次があるのでそちらを参考にしてください。

ドメイン駆動設計の基本を「ざっくり」理解できた

まず、ドメイン駆動設計のメリットを知れたのは良かったと思います。
本書では、4章の最初に触れています。
ドメイン駆動設計と手続きの設計を比較していて、これが分かりやすかったです。

私が普段使用している手続き型の設計では、データの保持と処理を明確に分離します。具体的には、データベースやWeb APIから取得したデータを格納するエンティティクラスを単なるデータの入れ物として定義し、それらのデータを操作する複数の機能クラスを組み合わせることで、目的の機能を実現していきます。

これに対しドメイン駆動設計は、ビジネスの概念や規則をクラスに落とし込みます。
落とし込んだクラスにロジックを書いていきます
こうすることで、ロジックが複数のクラスに書かれることを防ぐことができます。

手続き型による設計の場合、複数の機能クラスに似たようなロジックを書いてしまうことが多いため、ここがドメイン駆動設計の大きなメリットだと思いました。

その他にも、手続き型による設計との違いが書かれていて分かりやすかったです。
また、ドメイン駆動設計独自の専門用語も少なかったのもありがたかったです。

ドメインモデルを具体的にどうやって作るかイメージがわかなかった

ドメイン駆動設計周りの章は、サンプルコードが少なく、具体的な実装イメージが湧きづらかったと感じました。

一応、どうやってドメインモデルを作っていくかの説明はありましたが、抽象的・概念的な説明が多かったように感じます。(特に4章以降は全体的に)

主要な学び

以降、本書を読んだ際にメモしたことをそのまま乗せていきます。

ドメイン駆動設計を採用するとメソッドの置き場所に困らなくなる

ドメイン駆動設計の場合、「合計金額」のような項目をクラスとして表現する形になるため、
金額計算ロジックを、「合計金額」クラスに集約しやすい。

ドメインオブジェクトには基本となる設計パターンがある

基本的には、以下4つのパターンを組み合わせてドメインオブジェクトを作っていく。

ドメインオブジェクト 設計パターン
値オブジェクト 数値、日付、文字列をラッピングしてロジックを整理する
コレクションオブジェクト 配列やコレクションをラッピングしてロジックを整理する
区分オブジェクト 区分の定義と区分ごとのロジックを整理する
列挙型の集合操作 状態遷移ルールなどの列挙型の集合として整理する

上記の設計パターンは、本書でも詳しく解説されています。

進行役のクラスには、安易にロジックを追加しない

進行役(アプリケーションクラスまたはサービスクラスという)のクラスにロジックを書くと、他のクラスでの流用ができず、コードの重複が起きてしまう。
進行役クラスには業務ロジックを追加せず、

  • ドメインクラスを新しく作成する
  • 既存のドメインクラスを修正する方向で考えること

進行役クラスは、あくまでドメインクラスに指示を出すだけに徹することを意識する。

1つの画面の役割は1つに絞る

関心事を1つにすることでソースコードがシンプルになる
(用途に特化した小さな画面を用意することを、タスクベースのユーザーインターフェースという)
例:商品を購入する画面では、以下のタスクを行う専用の画面を用意したほうがいい。

  • 顧客情報の登録
  • 注文内容の登録
  • 決済方法の登録
  • 配送先の登録
  • 連絡先の登録
  • 注文の登録

逆に、何でもこなす汎用画面を作ってしまうとソースコードも肥大化しやすい。

総評

前半は、サンプルコードが多めで内容も具体的なものが多くて分かりやすかったと思います。
ですが、後半(特にドメイン駆動設計の話)は、サンプルコードが少なく説明も抽象的なので具体的な実装イメージが湧きづらいと感じました。

色々な設計パターン・原理・原則を知りたいなら、ミノ駆動本の方をオススメします。
サンプルコードも豊富なのでこちらのほうがイメージはつきやすいと思います。

当初の目的だった、「ドメイン駆動設計の基本について知りたい」については、
概ね達成できたと思います。
あくまで「ざっくり」とした理解で、具体的な内容はわかっていません。
もう少しサンプルコードが多めの入門書を買って勉強しようとは思いました。

どんな人におすすめか

  • 実務経験を3年以上積んでいる人
  • ドメイン駆動設計を概要を知りたい人

今後のアクション

ドメイン駆動設計のメリットやざっくり概要を理解できたので、
次はこの本で具体的にどうやってドメインモデルを作っていくか を勉強しようと思います。
ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?