Pythonで見るアーキテクチャパターン

 (cosmicpython.com)
5 ポイント 投稿者 GN⁺ 2025-03-29 | 2件のコメント | WhatsAppで共有
  • 『TDD with Python』の著者 Harry とソフトウェアアーキテクトの Bob が、複雑なソフトウェアアーキテクチャを理解し管理する方法を説明した本
  • EC 企業で実際に使われたアーキテクチャ手法を整理して共有
  • MADE.com はヨーロッパ拠点のオンライン家具販売会社で、グローバルなサプライチェーンを運営
    • 物流の最適化によって在庫を最小化し、消費者の注文と同時に物流が到着するよう調整することが目標
  • しかし現実世界は複雑で予測不可能なため、それを反映した知的なソフトウェアを構築して自動化している
  • 本書は、そのような実践的な課題を解決するために考案されたアーキテクチャパターンを扱う

なぜ Python なのか

  • Python は世界的に急成長している言語であり、ますます複雑なエンタープライズ課題に挑戦している
  • 既存のアーキテクチャ本の多くは Java や C# ベースの例を使っており、Python ユーザーには取っつきにくい
  • 本書は Python コミュニティに適した形でクラシックなアーキテクチャパターンを紹介する

TDD、DDD、イベント駆動アーキテクチャの紹介

  • TDD (Test-Driven Development):
    • テストファースト開発は、安定したリファクタリングと機能追加を可能にする
    • 高速で依存のない単体テストを優先し、低速で不安定な end-to-end テストは最小限にすべき
  • DDD (Domain-Driven Design):
    • ビジネスドメインモデルに集中しつつ、インフラやフレームワークへの依存を減らすことが重要
  • イベント駆動アーキテクチャ:
    • マイクロサービス間のメッセージベース通信で複雑さを管理
    • Flask、Django、Celery など既存の Python ツールとどう統合するかを考える必要がある

参考: 本書で扱うパターンの多くはモノリシックアーキテクチャにも適用可能

  • 本書の目的は、Python において TDD、DDD、イベント駆動サービスを支えるアーキテクチャパターンを紹介し、その適用方法を示すこと

本書の対象読者

  • 複雑な Python アプリケーションを扱った経験のある開発者
  • アーキテクチャパターンや DDD の背景知識がなくても問題ない
  • テストを先に書いて実装する TDD スタイルに慣れていなくても追える構成
  • Flask、SQLAlchemy、pytest、Docker、Redis などを使うが、必須知識ではない
  • 特定技術ではなく、技術に依存しないアーキテクチャ設計を目指す

学習内容の概要

Part 1

  • ドメインモデリングと DDD（1、2、7章）
    • 外部依存なしでドメインモデルを構築する方法を紹介
    • 高速な単体テストの書き方と、データ整合性との関係も考慮
    • 適切な Aggregate の選び方を説明
  • Repository、Service Layer、Unit of Work パターン（2、4、5章）
    • 永続化層を抽象化し、モデルを外部依存から分離
    • システムのエントリポイントとしてのサービス層を設計
    • Flask API や CLI のような薄いエントリポイントの構築に適している
  • テストと抽象化についての考察（3、5章）
    • 適切な抽象化レイヤーを選ぶ基準と役割を探る
    • 高い抽象化レベルで単体テストを書き、テストピラミッドを達成

Part 2

  • イベント駆動アーキテクチャ（8–11章）
    • Domain Events、Message Bus、Handler パターンを紹介
    • イベントを通じてシステム内の相互作用をトリガーする
    • イベントを使ってマイクロサービス間を統合する方法を説明
    • コマンド（command）とイベント（event）の違いを区別
    • アプリケーション全体がメッセージ処理システムへと変わる
  • CQRS (Command-Query Responsibility Segregation)（12章）
    • コマンドとクエリの責務分離による構造的効率を紹介
    • イベント使用の有無による実装例を含む
  • 依存性注入（13章）
    • 明示的／暗黙的依存を整理
    • シンプルな依存性注入フレームワークを実装

付録と実践ガイド

  • 既存プロジェクトへ適用する方法（エピローグ）
    • 単純な例よりも既存システムにパターンを適用するほうが難しい
    • そのための適用戦略と参考資料を提供
  • コード演習と GitHub サンプル
    • 本書の全内容を 1 つのサンプルプロジェクトとして構成
    • 各章ごとに GitHub ブランチでコードを提供
    • 演習方法:
      • 自分でサンプルアプリを作りながら実装する
      • 自分のプロジェクトにパターンを適用してみる
      • 各章の "Exercise for the Reader" を活用して練習コードを書く

ヒント: 各章の冒頭で GitHub の該当ブランチを checkout し、実際に動くコードと一緒に学ぶのがおすすめ

関連記事

2件のコメント

 
xguru 2025-03-29

日本語版が出ています。Pythonで見るアーキテクチャパターン
 
GN⁺ 2025-03-29
Hacker Newsの意見

  • この本はアーキテクチャパターンに関する宝の山のようなもの。主題を理解しやすい点が気に入っている

    • ただし実務では、こうしたパターンが複雑さや性能問題を引き起こすことがある。特に Django のように意見の強いフレームワークを使う場合はそう
    • 大きな会社と小さな会社の両方で Python を使った経験がある。厳格なアーキテクチャパターンを使う大企業ではコードは「クリーン」だが、複雑すぎて遅い
    • 一方で、パターンを無視した大企業ではコードは本当に散らかっていたが、生産性は高かった。コードが汚くても読めて、理解できて、修正できた
    • 自分自身のことかもしれないが、私は非定型なコードの会社のほうが生産的だった。クリーンコード論争を避けられたからだ

  • この本の一部は非常に有用。特に Python や特定の言語に限定されない概念を扱うとき

    • ただ、別の部分には問題もある。経験の浅い開発者がすべてを一度に実装しようとすると危険になり得る
    • たとえば、リポジトリパターンは一般には有用だが、本の例を含め、多くの場合は複雑さを増すだけでもある
    • サービスレイヤーと Unit of Work は複雑なアプリケーションでは有用だが、小さなサービスで構成されたシステムでは過度に肥大化することがある
    • デザインパターンは他のツールと同じく、いつ使うべきか、いつ使わないべきかを理解する必要がある。この本はその助言をしているが、もっと強調されるべき

  • Python は優れたグルー言語だと思う

    • 強制された OOP 的思考にうんざりしている。あらゆるものにカプセル化や継承を強いることにうんざりしている
    • SOLID、クリーンコーディング、クリーンアーキテクチャ、GoF パターン、Uncle Bob にうんざりしている
    • 命令型または関数型の流れに従い、できるだけ OOP を使わない
    • Python を使うときは、オブジェクトやパターンに縛られない体験を求めている
    • この本に価値がないと言っているわけではない。パターンを学ぶには有用だ。ただ、すべてを実際のプログラミングに当てはめるべきではない

  • 私は TypeScript 開発者だが、この本は最も好きなアーキテクチャ本の1つ。いつも参照している

    • テストのための偽の Unit of Work / サービスパターンを信条のように使っている。サードパーティサービスをフェイク化するのに役立つ
    • イベントはドメインに特化した形で命名することを勧める。これはチームメンバーに説明しづらい部分を解決してくれる
    • Cosmic Python がオンラインで完全公開されているのでリンクしやすい。全体として素晴らしく、形成的なリソースだ

  • 数年前から Python を仕事で書き始めた。Kotlin と TypeScript から来たが、言語自体はとっつきやすい一方で、疎結合とテスト容易性を実現するのに苦労していた

    • 同僚の勧めでこの本を買って最初から最後まで読んだ。複雑な Python コードベースで複雑さを管理する方法を理解する助けになった
    • すべてのパターンに従っているわけではないが、可能性や他のパラダイムでの経験を Python に適用する方法がわかった
    • 強く勧めたい。読む価値がある

  • 本当に素晴らしい Python プログラミング本の1つ。コードに静的型付けがないのは少し残念だったが、これは著者の意図的な判断だった

  • 素晴らしい資料の共有に感謝

  • この本のペーパーバックを2年半か3年前に読んだ。とても楽しかった。テストを第一級のテーマとして保ち、追加事項ごとに継続的に更新している

    • テストが準備されていて、書きやすく、更新しやすいことが、開発プロセスをより楽しいものにしてくれる。問題確認のために手動でコードを実行する必要が減る
    • イベント駆動の部分は興味深かったが、今の仕事で実装するには実用的ではなかった

  • Polylith への言及がない。関係があるのか気になる

  • この本は素晴らしい読み物だった。3年前に C#/.NET の DDD 環境で働いていて、今は Python でこれらの概念を再訪しながら、本質的な部分を洗練させている

    • こうしたテーマに興味があるなら強く勧めたい