レガシソフトウェアをメンテナンスするためのモデルベースのアプローチ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が最近リリースされ、重要な変...
Content-Length: 347935 | pFad | http://b.hatena.ne.jp/kamatama_41/DDD/
【ビッグローブ × DDD 〜ドメイン駆動設計の現場〜】で発表させていただきました。 - 「ノクターン（夜想曲）」からの人生復旧
devlove.doorkeeper.jp 縁あって、DevLoveのDDDイベントで発表させていただきました。 DevLoveの運営のみなさんや会場設営の会社メンバーに感謝です。 内容としては、以下の２部構成でした。 ビッグローブの事例紹介 登壇者と参加者によるディスカッション 事例紹介は、以下４パートに分割されて、僕は「2.導入」で発表させてもらいました。 立ち上げ：何故、ドメイン駆動開発に取り組もうとしたのか 導入：初期チームでの取り組みと、ファーストサービスリリース 現場でやってみて：ビッグローブでのDDD実践内容 これからの取り組み：組織でこれからドメイン駆動設計で向かうところ、組織でのメンバ育成について 各発表者の資料のリンクです。残念ながら、最初に発表したスライドはアップ不可とのことだったので、未掲載です。 20150616 dev love発表資料 from Mao Ohn
OOじゃないDDDについて - うさぎ組
概要 モデリングについていろいろ - Togetterまとめを読んでいて、前にも何度か言ったことがあるけれど、もう一度言っておこうかー的な感じです。多分ブログには書いていませんでしたので。 端的に言えば、パイプ&フィルターパターンがアプリケーションドメインであるアプリケーションもあって、そういったものはオブジェクト指向より関数型的なほうがうまく適合する可能性もあるという話。 DDDとプログラミングパラダイムやプログラミングスタイルは直交するはずだ Eric Evansから提案されたDDDはクラスベースOOを主体とした実例が多かったわけですが、DDDという概念はOOを前提としていないと僕は捉えています。特に、ユビキタス言語、コンテキストの明示、モデリングと密接な開発といった部分は多くのソフトウェア開発において役立つと言えそうですし、おそらくはプロダクト開発全体でも言えそうです。 エンティティ
ServiceとDCIについて - じゅんいち☆かとうの技術日誌
面白そうなネタがあったので、自分なりの考えをまとめてみる。 Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて この記事はRuby用のDIコンテナの話題なんですが、DCIについても言及されているようです。比較軸はDIそのものというより、サービスとDCIだと思うので、それについてダラダラといくつか考えをまとめてみます。多分も返事になるようでならないかも。それと宗教上の都合でDDDの視点から書きます…。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に”サービス”って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用するためのものです。後者はドメインの知識
ソフトウェア設計のすすめ
社内LTでソフトウェア設計のすゝめを比較的新しいエンジニア向けにしたので、その資料を公開します。Read less
ドメインモデルの完全な状態を保つ方法
非常に面白い話題ですね！ちょっと簡単にまとめてみました。参考になれば幸いです。 話は若干逸れますが、そもそも相互参照がつらいって話があるので、その話から。DDD二部 関連の章を読んでいたら理解できると思いますが、双方向の関連は仕様を満たしているか検証する実装コストが高いと思います。 Line line = new Line(id); Point point = new Point(id); point.setLineId(line.getId()); // --- (A) line.addPoint(point); // --- (B) この場合、(A), (B)は両方の状態が正しく設定されていないといけません。しかし、実際は(A)もしくは(B)の参照の設定を忘れてしまうと、どちらが正しい状態を示しているか見分けがつかなくなります。 まぁ、それだけ参照が増えるというのは設計や実装が複雑にな
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
Scalaコードでわかった気になるDDD | GREE Engineering
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
コードで学ぶドメイン駆動設計入門 〜アグリゲート編〜 - かとじゅんの技術日誌
コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜振る舞いとサービス編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜ファクトリ編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜リポジトリ編〜 - じゅんいち☆かとうの技術日誌 引き続き連投エントリ。次はアグリゲート。 実は最近まで「アグリゲートってなんだろう、、ライフサイクルの話題なのか」なって誤認識してたのですが、もう一度原書を読みなおして、やっと理解。まぁ、このパターンはすでに実施していたので、改めてこれはアグリゲートという名前かと知ったという次第。 つまるところ、アグリゲートとは、簡単にいうとライフサイクルを取り扱う境界のことですね。そもそも、Aggregateとは集約という意味があって
ナチュラルキーとサロゲートキーについての議論
とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー（代理キー）」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル（≒行）の値を一意に決定することができる属性（≒カラム）の集合」の
ユビキタス言語とドメインモデル、そしてモデル探求うずまき - じゅんいち☆かとうの技術日誌
最近、ドメイン駆動設計ってどうやって実践すればいいかなーという質問をよくされるので、この記事が満額回答にはならないと思いますが、書いてみたいと思います。 シンプルな問題はトランザクションスクリプト、いわゆる手続き型で対処できます。問題が小さいのでコードは直接的でわかりやすくなる傾向にあります。 とはいえ、世の中の問題はシンプルなものばかりじゃない。複雑な問題もある。DDDの著者であるEric氏は、複雑な問題はドメインモデルを使って対処すべきと説く。 ドメインとは問題の領域とか知識の範囲をいうのですが、DDDはそのドメインにある概念をモデル(ドメインモデル)として定義して、さらに実装として紐付けていく設計手法です。 モデルクラスは概念ありき 例えば、電車にまつわるドメインというので考えたとしたら 電車 乗客 駅 ダイア などの概念が登場します。 現実世界に限った話ではなく、仮想世界でもドメイ
最近のおっさんたち - steps to phantasien
Gisted のドッグフードをかねて InfoQ のインタビューやプレゼンを見るようになった。 いくつか面白かったのを紹介したい・・・とおもってるうちにバックログを溜めすぎた。一度に紹介するのは諦めて何度かにわけよう。 今日はおっさん、具体的には ThoughtWorks 周辺の面々を追いかけてみます。InfoQ 中心だけどそれ以外も若干あり。 When Geek Leaks “プロダクティブ・プログラマ ” の著者 Neal Ford が あるキーノートにつけたタイトルは ”When Geek Leaks“。 ここでの Leak は前向きだ。Geek の情熱がその主たる関心の外にも影響を与えていくといいですね、という話。 ファインマンが物理学という専門以外で発揮した数々のいたずら心、 ”Now Every Company Is A Software Company” という Forbes
DCIアーキテクチャについて語ってみるよ - uehaj's blog
Trygve Reenskaug氏とJames O. Coplien氏らが提唱する「DCIアーキテクチャ」について、id:digitalsoulさんが論文を翻訳してくださり、またその解説とサンプル実装(groovy, scala)を示してくださっており、読んでみたところ、大変興味深いので理解した限りを書いてみます。 おじさん登場 たとえば、あるおじさんがいたとします。 このおじさんは、白いスーツ、グラデーションの入ったサングラスと金ぴかのネックレスをつけて新宿歌舞伎町に出かけ「やくざ」として振るまいます。とおりかかったお兄さんがそのおじさんに出会い、目が合ってしまい、因縁を付けられ、お金を巻き上げられてしまいます。 さて、おじさんは家に帰ります。実は、このおじさんは家では良いお父さんとして振る舞います。赤ちゃんはこのおじさんの目を見て笑いかけます。おじさんは相好を崩し、オーよしよし。 さて
DCIアーキテクチャについて勉強してきた #あーだCoder - 亀岡的プログラマ日記
第二回あーだCoderをやってきました。 - #あーだCoder 第二回 - connpass 解説すると、あーだCoderというのは僕と@irofさんの間で勝手に盛り上がっていつの間にかconnpassたったのでとりあえずやってみるかと始まったコード中心にモデル実装なんかを語る場。 今回は割りとじっくりとコードを見て、それから解説をしてもらいました。 特に興味深かったのが@ktz_aliasさんのコード。 - Codersation/TDDBC_VendorMachine/ktz_alias at master · posaunehm/Codersation · GitHub Data Context Interaction : DCIアーキテクチャ、というのがあるらしくて（本気で初耳）、それについてつらつらと議論して（というか教授してもらって）いました。 とりあえず、札幌Ruby会議で
現実世界におけるルールエンジン
これらのビジネスルールは新しいものではありません。多くのビジネスソフトアプリケーションの中核となるビジネスロジックです。もしあなたが開発者なら、こうしたルールは要件のサブセットとして表現されているのを何度となく見たことでしょう。これらは、"月曜日は、3つ以上のご注文で20%のディスカウント"や"スーパースポーツ・バイクでは、16才の男性に保険を掛けることはできません"といった文章に似ています。 ルールエンジン間の主な違いは、こうしたルールがどう表現されるか、です。プログラムの中に埋め込まれる代わりに、これらはビジネスルールの書式に符号化されます。この書式はルールエンジンごとに違っています。 ルールエンジンは、何の制限も受けていません。ルールを管理するための、他のツールと一緒にリリースされることがよくあります。一般的なオプションとしては、生成、デプロイ、保存、バージョニング、そして個別もしく
InfoQ: ドメイン駆動設計・開発の実践
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
ドメインモデル駆動開発の実践 | システム設計日記
今のプロジェクト「ドメインモデル駆動開発」に、こだわって、やっている。 ドメインモデル駆動開発（DMDD:Domain Model Driven Development) は、モデリングや設計よりも、実際のコードの書き方が、主要な関心事。 やり方 具体的、かつ、簡単。 基本のアイデアは、Eclipse プロジェクトを、レイヤごとに、別々に作成すること。 （１）まず、ドメイン層のプロジェクトを作って、ドメインのクラス群を作る （２）次に、データベースを定義する （３）次に、データアクセス層の プロジェクトを別に作って、ドメイン層プロジェクトを参照する。 O-R マッピング ( SQL Map ) の仕組みを使って、ドメイン層で宣言した、 Repository インタフェースを、実装する。 （４）次に、サービス層のプロジェクトを、さらに別に作る。 このプロジェクトも、ドメイン層プロジェクトを参
OTN Japan - 今だからデータ・アクセスを真剣に考える！ 第1回
システムを構築する上で必須となるデータベースアクセスの機能、皆さんはどのように実装しているでしょうか？JDBCで記述/EJB Entity Bean(BMP/CMP)を利用/データアクセスフレームワークを利用、等様々な実装方法を選択されているかと思います。 この連載では、様々な観点からデータアクセスに関わる事項を取り上げ、皆ささんがデータベースアクセスについて、少し考えてみる場になればと思っています。まず今回のデータアクセスことはじめ（前編/後編）では、これから様々なデータベースアクセスに関する事項を扱っていく上でのベースとなる知識を取り上げます。 現在、Javaプログラミング言語を用いてエンタープライズシステムを開発する場合、要件変更への設計・実装の変更の容易性、JDBC、EJB Entity Beanなどのデータアクセス要素技術とのマッピングの容易性、等々の理由により、システム全体を論
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/kamatama_41/DDD/
Alternative Proxies:
ドメイン駆動設計の間違った方向性
ドメインドリブンデザインはDIやAOPなしでも十分な実装可能か？
