ドメイン駆動設計基礎講座〜戦略編〜ChatWork社内勉強会で発表した際の資料
「ドメイン駆動設計」の複雑さに立ち向かう
13. オブジェクト指向の「変更容易性」 (どのパラダイムでも同じだけど） • 抽象データ型／段階的な抽象化 – プログラムを人間の発想に近づけると扱いやすい • モジュラープログラミング – 独立性の高い部品に分けると扱いやすい – 関連するデータと操作は、ひとつのプログラミング単位に • メッセージング – 部品の組合せを柔軟に変更できると扱いやすい – sender/receiver/dynamic routing – Javaだとうまく実現できていないアイデア • メッセージングの考え方の参考 • Erlang, EIP:Enterprise Integration Patterns, マイクロ サービス, …
いまなぜドメイン駆動設計か
8. いまなぜＯＯ&ＸＰか？ • 小規模・短納期のWebアプリケーション開発の機会が増えた – スマートフォンアプリのバックエンドとかも含めて – 作って動かすだけなら簡単にできるようになった (たとえばRoR) – 多産多死？ • 技術もニーズも変化が激しく、全体をじっくり分析・設計している開 発スタイルでは対応できない • 生き残ったアプリケーションは、修正や拡張のニーズが多いが、設 計が貧弱だと、うまく対応できず、あったいうまにレガシー化する オブジェクト指向の「変更容易性」 エクストリーム・プログラミングの「変化適応性」 9. 開発スタイル YAXP:もうひとつのXP • とにかく動くソフトウェアを作り続ける • 究極のエクストリーム・プログラミングw • Web系のアプリケーション開発現場の実態？ スタイル 例 最終形 （着地点） フェーズ分け 予測型 ウォータフォー ル 事前に
個別案件にオブジェクト指向は要らない - 設計者の発言
「ウォーターフォールかアジャイルか」をはじめとして、ソフトウエア開発手法に関してさまざまな議論があるが、すべてのソフトウエアをいっしょくたにすべきではない。たとえば「ＥＣサイト」と「業務システム（基幹業務支援システム）」とは、同じ「データベースシステム」に分類可能だとしても、専門性が大きく異っている。両者をまとめて議論しても実りが多いとは私には思えない。 私の専門は「業務システム」なのだが、次のように勘定科目と密接な関係を持つ複雑なデータ構造を扱う点が特徴的である。 ＜サービス業向け販売管理システム＞ ・発注、買掛残高、仕入実績、支払 ・受注、売掛残高、売上実績、原価実績、請求 ＜物販業向け販売管理システム＞ ・発注、買掛残高、仕入実績、支払 ・受注、売掛残高、売上実績、請求 ・在庫残高、受払実績、棚卸、倉庫移動 ＜生産管理システム＞ ・発注、買掛残高、仕入実績、支払 ・受注、売掛残高、売
ドメイン駆動設計入門 - Digital Romanticism
"Beautiful Develpment"（10/27 DevLOVE）の講演資料と原稿 はじめに 本日（10/27）、DevLOVE様主催で、"Beautiful Develoment"と題されたイベントが開催されました。これは「ドメイン駆動設計（"DDD:Domain-Driven Design"）」を題材に、入門から実践までを語り尽くすというコンセプトのものです。このイベントにおける講演のトップバッターとして、ドメイン駆動設計の根底にある基本的な考え方についてお話しさせて頂きましたので、講演資料と原稿を公開いたします*1。 スライドはこちら アジェンダは以下の通りです。 導入 オブジェクトとは？ モデルとは？ ドメイン駆動設計とは？ まずは、ドメイン駆動設計のベースとなっている、「オブジェクト指向」や「モデル」について整理した上で、実際にドメイン駆動設計とはどういうものかを見ていき
ドメインロジックの実装方法とドメイン駆動設計
4. 3 層アーキテクチャ エンタープライズアプリの典型的アーキテクチャ Web アプリ FW サービスレイヤー DI ／ IoC コンテナ データアクセス FW DAO プレゼンテーション層 ドメイン層 インテグレーション層 POJO アクション アクション アクション POJO POJO POJO DAO インテグレーション ゲートウェイ システム間統合 MW FW ・・・ フレームワーク MW ・・・ ミドルウェア ルールエンジン ワークフローエンジン 5. ビジネスにとって最も重要な部分 Web アプリ FW サービスレイヤー DI ／ IoC コンテナ データアクセス FW DAO プレゼンテーション層 ドメイン層 インテグレーション層 POJO アクション アクション アクション POJO POJO POJO DAO インテグレーション ゲートウェイ システム間統合 MW
ドメイン駆動設計 | システム設計日記
テスト駆動開発 和田卓人(t-wada)さんによる『テスト駆動開発』の新訳版が出版されました。 オブジェクト指向でソフトウェアを開発するのであれば、この本とマーチンファウラーの『リファクタリング』は必読書だと思います。この古典ともいえる『テスト駆動開発』が和田さんの手によって新訳版として復刊されたことは、ほんとうにすばらしいことです。 この本が出版された経緯と、和田さんはじめ関係者の方々のご努力については、和田さんの、このブログをぜひ読んでいただければと思います。 新訳版『テスト駆動開発』が出ます 新訳本は、単に原著が日本語で読めるようになっただけではありません。和田さんの手によって、原著にはない新たな価値が付け加えらました。 一つは、サンプルコードの工夫です。 できるだけ省略はしない変更箇所を目立つようにした各章末にその時点での全コードを記載する これらの工夫により、本に書かれた内容が、
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン駆動設計 基本を理解する
実践に向けたドメイン駆動設計のエッセンス
ドメインモデル中心のアーキテクチャ | GuildWorks Blog