あなたのORMの使い方は間違っているSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
Object design rough talksへ行ってきました - 虎塚
金曜の夜、Object design rough talksへ行ってきました。Twitterのハッシュタグは #ObjectDesign でした。 Object design rough talks on Zusaar http://www.zusaar.com/event/5037004 面白かったトークの抜粋と感想を書きます。 t_hysshさん「オブジェクト指向レッスン」 内容 『TohughtWorksアンソロジー』から引用したオブジェクト指向で実装するためのルールと、林さんが独自に考えられたルールの紹介でした。 感想 こういったルールは、チームでコーディング方法を統一することを目的とするなら機能しそうだなぁと思いました。 また、林さんは、実際に仕事でチームに適用したところそこそこ上手くいったとおっしゃっていたので、オブジェクト指向を理解している人が、そうでない人のコードをレビュー
ServiceとDCIについて - じゅんいち☆かとうの技術日誌
面白そうなネタがあったので、自分なりの考えをまとめてみる。 Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて この記事はRuby用のDIコンテナの話題なんですが、DCIについても言及されているようです。比較軸はDIそのものというより、サービスとDCIだと思うので、それについてダラダラといくつか考えをまとめてみます。多分も返事になるようでならないかも。それと宗教上の都合でDDDの視点から書きます…。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に”サービス”って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用するためのものです。後者はドメインの知識
和田卓人さん出題のテスト駆動開発問題『現在時刻とロケールに依存するテスト』をPHPを使ってオブジェクト指向で解答してみました #php #object_oriented｜CodeIQ MAGAZINE
テスト駆動開発の巨匠・和田卓人さんからの『現在時刻とロケールに依存するテスト』問題をPHPメンターズの後藤秀宣さんが解答してくださいました！ この記事は、その後藤さんによる解答コードの公開と解説記事になります！！ by CodeIQ運営事務局 PHPメンターズの後藤です。 和田卓人さん出題の『現在時刻とロケールに依存するテスト』問題をPHPを使ってオブジェクト指向のアプローチで解答してみました。 ※問題文については、和田卓人さんの解説記事を参照にしてください。 https://codeiq.jp/magazine/2013/11/1475/ 解答例は次の環境で作成しています。 PHP 5.5.4 PHPUnit 3.7 Composer サンプルコードのリポジトリをGitHubにて公開しています。コミットログなど合わせてご参照ください。（解説中にも各コミットへのリンクを貼ってあります） g
ウェブアプリケーションの構造について - かとじゅんの技術日誌
日経ソフトウエア 11月号の特集2で「最新Eclipseで良いJavaプログラムを書こう」に関連する話題として、さらに視野を広げて実用的なウェブアプリケーションでのレイヤー構造とかドメインオブジェクトの関係はどうなるのか？という点について解説してみたいと思います。(まだ日経ソフトウエア11月号を手にしていない方はぜひ買ってくださいw) 結論から先に出しますが、ドメイン駆動設計では一般論として下図のようなレイヤー構造やオブジェクトの関連が提唱されています。 ドメイン層のオブジェクトについては変わりないのですが、ドメイン以外のレイヤーに新しく２つのサービスが登場しているので、まずそこから簡単に説明します。 ドメイン層以外のサービス 実はサービスはドメイン層だけではなく、アプリケーション層とインフラストラクチャ層にも存在する場合があります。その役割を以下にまとめてみました。 レイヤー オブジェク
ドメイン層の構造の改善 ： Evolving Order パターン | システム設計日記
ドメイン層のオブジェクト群を、どういう視点で整理し、ドメイン層の構造を、どうやって育てていくか？ アプリケーション全体の構造 私たちのデフォルトのレイヤアーキテクチャは、 ■インタフェース （UI、REST API、... ) ■アプリケーションサービス ■ドメイン ■インフラストラクチャ（永続化、メッセージング） です。 アプリケーションサービスは、ドメイン層の薄いファサード。 実際の仕事は、ドメインのオブジェクトに委譲する。 ドメインで扱うデータの種類が増え、ビジネスのロジックが膨らんでくると、ドメイン層も、構造化して整理しないと、わけが分からなくなる。 初めはトランザクションスクリプトだった ドメイン駆動設計に取り組み始めたころは、ドメイン層の設計パターンは、ドメインモデルではなくトランザクションスクリプトでやっていた。 ユースケースごとに トランザクションスクリプトのクラスを作って
ドメインロジックの実装方法とドメイン駆動設計
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
C#と諸々 ドメインモデル貧血症
C#がメインで他もまぁ諸々なブログです おかしなこと書いてたら指摘してくれると嬉しいです(´･∀･`) つーかコメント欲しい(´･ω･｀) Martin Fowler's Bliki in Japanese - ドメインモデル貧血症 有名なアンチパターンです。僕も昔やってしまったことがあります。 例えば、図書の貸出システムを作るとします。このシステムは利用者が直接操作し、借り入れ手続きや返却手続きを行います。 ドメインモデルを適切に適用した設計では、「書籍」クラスや「利用者」クラスを用意し、「利用者」クラスに「借りる」メソッドや「返すメソッド」を用意するでしょう。 public sealed class 書籍 { public int 管理番号 { get { ... } } public string タイトル { get { ... } } public string 著者 { get
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
20110409_DevLOVE「Building Blocks」_都元ダイスケさん
20110409_DevLOVE「実践！ ドメイン駆動設計」_増田亨さん
ドメイン駆動設計 の 実践 Part3 DDD