タグ

DDDに関するurza358のブックマーク (2)

  • 実践DDD本 第4章「アーキテクチャ」 ~レイヤからヘキサゴナルへ~

    前回記事:IDDDの第3章「コンテキストマップ」の解説 稿で紹介するアーキテクチャの種類 エバンズでは、DDDのアーキテクチャは「レイヤアーキテクチャ」を中心に紹介していました。これに対してIDDDでは「ヘキサゴナルアーキテクチャ」を提唱しています。さらにヘキサゴナルアーキテクチャと関係が強い「サービス指向(SOA、REST)」「コマンドクエリ責務分離(CQRS)」「イベント駆動アーキテクチャ(パイプ&フィルター、長期サーガ、イベントソーシング)」といった概念やアーキテクチャ方式についても取り上げています。 特定のアーキテクチャに依存しないDDD DDDは特定の技術に依存していないため、自由にアーキテクチャを選択することができます。アーキテクチャの選定においては、構築するシステムに求められる「機能要求(ユースケース、ユーザーストーリー、ドメインモデルのシナリオ等)」と「品質要求(性

    実践DDD本 第4章「アーキテクチャ」 ~レイヤからヘキサゴナルへ~
  • ドメイン駆動設計を理解する3つのキーワード - ソフトウェア設計を考える

    ドメイン駆動設計との出会い 10年前に、エヴァンスのドメイン駆動設計を初めて読んだ時は、書いてある内容がほとんど理解できなかった。 あまり、面白いとも思わなかった。 当時は、現場でバグだらけのコードと格闘していた。障害が報告されるたびに、リファクタリングを参考に、該当個所の長いメソッドや大きなクラスを片端からリファクタリング。その結果、コードがわかりやすくなり、やっかいなバグが単純な修正で解消できてしまうことの効果に驚き、設計の重要性を再認識していた。 それ以前は、UNIXとC言語、OracleとPL/SQLという、オブジェクト指向ではない世界で技術を身に着けてきた。 どちらかというとオブジェクト指向には、ネガティブな印象を持っていた。現場では役に立たんだろうと。 バグとの格闘の中で、リファクタリング(設計改善)の威力を肌で感じ、その考え方とやり方がオブジェクト指向に由来するということを

    ドメイン駆動設計を理解する3つのキーワード - ソフトウェア設計を考える
  • 1