1
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?

ちょうぜつ本で学ぶクリーンアーキテクチャの誤解とパッケージ原則の重要性

Posted at

この記事はちょうぜつ本 1 周年 Advent Calendar 2023 の24日の記事になります。

ちょうぜつ本の推薦理由

ちょうぜつ本おすすめする理由は設計スキルを向上させ、初級者から中級者へのステップアップを目指す方々に最適な教材であるという点にあります。

設計の初学者から初級者向けには、例えば「良いコード/悪いコードで学ぶ設計入門」(通称:ミノ駆動本)のような多くの入門書が出版されています。また、アンクルボブによる「クリーン〇〇」シリーズなど、中級者以上を対象とした書籍も長く人気を集めています。

しかし、初級者が中級者へと進むための適切な教材は、これまで比較的少なかったのです。「ちょうぜつ本」は、このようなギャップを埋めるために推奨されています。本書は、現代のチーム開発に不可欠な設計原則を、中級者にも理解しやすく解説しており、初級者が既に学んだ知識を再確認し、次のレベルへの挑戦に適しています。

サンプルコードはPHPで書かれているため、PHPプログラマーには特に有用ですが、理論的な部分はPHPの経験がない方にも実践的な内容として十分に役立ちます。

この本は幅広く扱われていますが、今回は本の最初の章であるクリーンアーキテクチャとパッケージ原則について簡単に説明をします。

クリーンアーキテクチャはレイヤーの依存性を解説している

スクリーンショット 2023-12-20 12.39.15.png

クリーンアーキテクチャは、図によって広く知られるようになりましたが、このことが誤解を生んでしまった面もあります。図に示された構造を実現すること自体が重要であると誤解されていることがあります。
実際には、それよりも依存性のルールの重要性を理解することがより大切です。

ロバート・C・マーティンは、クリーンアーキテクチャの本のなかで以下のように記述しています

図221では、クリーンアーキテクチャの概要が示されていますが、これはあくまでも一例に過ぎません。この4つの層以外にも、必要なものが存在するかもしれません。しかし、依存性のルールは常に適用されます。ソースコードの依存性は、常に内側に向けるべきです。内側に近づくほど、抽象度と方針のレベルは高まります。外側には具体的な詳細が存在し、内側にはソフトウェアの抽象化された高位レベルの方針がカプセル化されます。最も内側は、最も一般的で高位レベルのものになります。

(引用:ロバート・C・マーティン, 角 征典, 高木 正弘, 「クリーンアーキテクチャ 4つの円だけ?」より)

レイヤーを意識した設計をする場合は図が示す4つの層―ドメインモデル、ユースケース、プレゼンテーター、インフラストラクチャ―が存在する事が多いですが、それが3つや5つとかでも問題ないと言えます。

クリーンアーキテクチャはレイヤーを意識してそのレイヤー間の依存性についてもっとも重要した考え方である。そのレイヤーは内側びドメインに関するクラスだけが存在する、一番外側はドメインとは全く関係ないDBなどが存在するという方が個人的にはあっていると思います。

パッケージ原則で認知負荷をさげる

パッケージ原則は、特に大規模なプロジェクトで重要な役割を果たしますが、理解するのが難しい点もあります。

たとえばRailsでは、アクティブレコードのクラスは通常 app/models 直下に作成されます。しかし、中規模以上のプロジェクトではこの構造がもたらす課題も存在します。具体的には、どのファイルがどこにあるのかが分かりにくくなることや、たくさんのファイルがあるため関係しないファイルも同じディレクトリにあるため気になってしまうなどの理由によりプログラミング時の認知負荷が増大します。

このような状態を説明するのに中規模のECサイトのモデルのファイルリストを例に出します。
以下のファイルリストがパッケージを無視したディレクトリ構造です。

├── cart.rb
├── cart_item.rb
├── category.rb
├── category_tag.rb
├── coupon.rb
├── credit_card.rb
├── customer
├── customer.rb
├── customer_address.rb
├── customer_churn_prediction.rb
├── customer_complaint.rb
├── customer_insight.rb
├── customer_lifetime_value.rb
├── customer_order_history.rb
├── customer_preference.rb
├── customer_profile.rb
├── customer_satisfaction_metric.rb
├── customer_wishlist_analysis.rb
├── discount.rb
├── discount_rule.rb
├── inventory.rb
├── marketing_campaign.rb
├── order.rb
このようなファイルがあと15個ある

このように非常にわかりづらい状態になっています。

パッケージ原則に従ってパッケージを作成すると以下のようになり先程あげたプログラミング時の認知負荷を下げることができます。
customer_only.png

この場合だとCustomerに関連するモデルを編集する際、関連ファイルのみを確認することで済むようになります。

パッケージ原則はいくつかありますが、私がパッケージ原則を理解する中で難しかった「リリース再利用等価原則」「共通再利用原則」「共通クロージャー原則」に関しては
関連する機能を同じパッケージ内にまとめ、その変更がパッケージ内で完結するように設計することで原則に従った設計ができているのではないかと思います。

パッケージ原則を用いることで、特に中規模以上のシステムを開発する際に認知負荷を軽減し、より効率的なプログラミングが可能になります。
今回は説明できませんでしたが、パッケージ原則はパッケージをいかに安定させるかの項目もありそれも中規模以上のシステムを開発する場合は重要です。
今回の説明を通じて、パッケージ原則の重要性と効果について、興味を持っていただければ幸いです。

まとめ

今回はちょうぜつぼんの中で重要だと思った
クリーンアーキテクチャはレイヤーの依存性を解説しているパッケージ原則で認知負荷をさげるということについて説明しました。

冒頭に説明したように、今回私が説明したところ以外にもちょうぜつ本は設計等に関することを幅広く学習ができるおすすめの本です。

1
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
1
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?