ドメインモデル中心のアーキテクチャ | GuildWorks Blog
リーンなコードを書こう：実践的なオブジェクト指向設計
DevLove仙台 オブジェクト設計とリーン開発、その実践 変更しやすく、コードを改善するRead less
Railsでサービスとフォームを導入してみる話 - assertInstanceOf('Engineer', $a_suenami)
この記事はRuby on Rails Advent Calendar 2013の6日目の記事です。 前日は @tkawa さんの「Favoriteの設計実装はパターンとして使える」でした。 Railsで適切に責務を分割するということ RailsはいわゆるMVCと呼ばれるアーキテクチャパターンにのっとったフレームワークであり、プロジェクトを作成するとデフォルトでmodels/、views/、controllers/などのディレクトリが作成されます。 基本的にロジックを記述する場所はモデルであり、ビューには表示処理だけを、コントローラにはアプリケーション上必要な手続きだけを記述するべきであると一般的には言われています。*1 ただ、それを忠実に実践していった結果、モデルが肥大化しメンテナンシビリティやテスタビリティが低下するという問題も多く指摘されています。 これについては4日目に @joker
Domain Patterns in Enterprise Projects · JVM. Blog.
If I had to separate projects I've been in, i would difference between data manipulation and enterprise projects. Data manipulation projects mainly consist of a set of forms needed to alter data which is stored in some persistent store (most of the time a relational database). In these projects, there is not much domain logic to be found. There might be some validation logic, some jobs running in
Agile開発に足りないもの～モデリング技術 - プログラマの思索
@hatsanhatさん、@sugimoto_keiさんと議論していて、TiDD＋DOAで開発できないか、と考えたことをメモ。 ラフなメモ書き。 下記はあくまでも僕の一意見。 間違っていたら後で直す。 【1】「DOAとRailsは相性が悪い」という意見はよく知られている。 でも、逆に、Railsだからこそ、DOAがより重要になってきた気がしている。 RailsでWebアプリを作っていると、どのようなテーブル設計が良いのか、という問題に結局ぶち当たる。 更新時異常が発生しないようなテーブルを設計するのは、そんなに簡単な技術ではない。 以前、Ruby関西の勉強会でも渡辺さんが講演した時もあったが、その講演の発端もその問題にあったのだろうと思う。 丁度それは、Agile開発がシステム開発をHowの問題に落とせれば高速・高品質に開発できるけれども、WhatやWhyの部分ではまだ手持ちの武器が少ない
ドメイン駆動式ソフトウェアの育て方 - Digital Romanticism
レッツゴーデベロッパー2011での発表原稿とスライド 導入 2011年05月28日「レッツゴーデベロッパー2011@仙台」が開催されました。このイベントのテーマは「共有と交流」。"「共有」には、最新技術、知識、復興への想い、それぞれの決意を共有することを、「交流」には、東北と東北圏外のデベロッパーやコミュニティ同士の交流を深めることを込めて。" このイベントにてDDDセッションに登壇させて頂きましたので、そのときの発表原稿とスライドを公開致します。なお、当日はワークとして参加者の方にペアモデリングを行って頂きましたが、このドラフトではその部分を割愛しています。 スライドはこちら また映像はこちらで公開して頂いています。 さて今年4/9にDDD日本語版が出版されました。それから２ヶ月弱、翔泳社様から、はやくも増刷のお知らせを頂きました。多くの方々とおかげと深く感謝しています。さて、この増刷が
Spring Rooのレイヤアーキテクチャ | かサハラノリオ |泳ぎ|漕ぎ|走り|ながら考える
先日の記事を詳細化していこうと思う。Spring Rooは、エンティティ層-Web層というシンプルな2層構造になっている。 レイヤを多層化し、責務を明確化することで、コードの可読性や変更性は向上する。なぜなら、どこに何が書いてあるか探しやすくなるし、DRY原則を徹底することができるから。 しかし、レイヤが多層になるほど、アーキテクチャは複雑になり、生産性は落ちる。一例としては、ドメインモデルの各レイヤへの射影が必要になることが挙げられる。永続化のレイヤでは、JPAやHibernateの永続化オブジェクト、プレゼンテーション層では、入力や表示しやすい形式(プレゼンテーションモデルと呼ばれることもある)での表現。サービス層ではこの2つを仲介するためのDTO。レイヤを行き来するためには、本来的には同じエンティティでありながら、表現形式の異なるこれらのオブジェクトの「詰め替え」がいちいち必要になる
戦略的設計入門 - Digital Romanticism
"Beautiful Development"（2011.04.09 DevLOVE）の講演資料と原稿 はじめに 本日（4/9）、DevLove様と共同で、第２回"Beautiful Development"を開催致しました。これは、日本語版DDDの発売を記念し、DDDに造詣の深い方々に集まって頂き、２枠構成で講演して頂くという豪華なものでした。このカンファレンスでトリを務めさせて頂きましたので、講演資料と原稿を公開致します*1。なお、今回の発表は「ドメイン駆動設計入門」では駆け足でまとめてしまった部分を、改めてクローズアップした続編と考えて頂くこともできるでしょう。 アジェンダはこちら 戦略的設計とは？ サンプル業務 モデル駆動設計をすると？ 戦略的設計 スライドはこちら 戦略的設計とは？ 「戦略的設計（Strategic Design）」とは、DDD第４部のタイトルです。DDDは全体で
DevLoveのBeautiful Development（DDD勉強会）に参加してきました - 達人プログラマーを目指して
昨日、DevLoveの主催するBeautiful Development（ソフトウェアの核心にある複雑さに立ち向かう）という勉強会に参加してきました。 https://sites.google.com/a/devlove.org/development/past-beneficiaries/devlove_ddd2 今回は、Domain-Driven Design（DDD）をテーマにした勉強会でした。ここで簡単にレポートさせていただきたいと思います。 勉強会参加のすすめ 実は、DevLoveの勉強会に参加するのはまだ今回が2回目です。*1 このように私自身もまだDevLove初心者なのですが、今回は初参加の人がかなり大勢いたようです。*2こういった技術者の勉強会というと、初心者お断りというか、相当の予備知識があったりOSSコミュニティーに貢献したりしていないと参加してはいけないのでないかと
QCon Tokyo 2011 アーキテクチャパネルディスカッション＋DDD雑多ネタ
アーキテクチャパネルディスカッションとラウンジ・ビアパーティでの雑談から、主にDDDに関して興味深かった話をいくつか。聞き取り能力は低いので抜けている部分もあると思いますがご容赦を。 ビジネス的な有用性はどこにあるのかEvans氏発言要旨 経営層など意思決定を行う人たちに対して、ドメイン駆動設計の有用性をどう訴えかけるのか？という問いに対して、Evans氏は主にコアドメインへの注力によって競争上の優位、市場優位につなげる部分を強調。ここから一段階細かいレベルとして、ビジネスパーソンにとって理解できるソフトウェアへと進んでいくとのこと。ただし、常に労力に見合う価値が得られるわけではないことも忘れずに付加。 雑感この質問はなかなか難しく、聴衆の反応も微妙なものだったように思う。これは、DDDをオブジェクト指向設計方法論として受け取っている人が多く、こうした部分の有用性についての回答を期待してい
Domain Driven Design with Spring and AspectJ - Java Code Geeks
Tomasz NurkiewiczFebruary 21st, 2011Last Updated: October 24th, 2012 In a previous post hosted at JavaCodeGeeks, our JCG partner Tomasz Nurkiewicz presented an introduction to Domain Driven Design using the State design pattern. At the end of that tutorial, he admitted that he had left out the process of how to inject dependencies (DAOs, business services etc.) to the domain objects. However, he p
ドメイン駆動設計を始めるときにおすすめなコード例 - かとじゅんの技術日誌
ドメイン駆動設計で開発する時に、まずお手本となるコード例をみたいですよね。 まず、これ見ましょう。 DDDSampleは、Javaで実装されたものです。*1 原書の内容と連動しているので、原書を読んでいる人にとっては分かりやすいと思います。読んでいなくても、概念を抑える前に具体的なコードで実態を把握しておいて、本を読んでもいいと思います。 ちなみに、このあたりを見ていただくと、ドメインオブジェクトを規定するためのインターフェイスが定義されています。 http://dddsample.svn.sourceforge.net/viewvc/dddsample/trunk/dddsample/tracking/core/src/main/java/se/citerus/dddsample/tracking/core/domain/patterns/ このインターフェイスを参考に別のライブラリに切
ドメイン駆動設計入門 - Digital Romanticism
"Beautiful Develpment"（10/27 DevLOVE）の講演資料と原稿 はじめに 本日（10/27）、DevLOVE様主催で、"Beautiful Develoment"と題されたイベントが開催されました。これは「ドメイン駆動設計（"DDD:Domain-Driven Design"）」を題材に、入門から実践までを語り尽くすというコンセプトのものです。このイベントにおける講演のトップバッターとして、ドメイン駆動設計の根底にある基本的な考え方についてお話しさせて頂きましたので、講演資料と原稿を公開いたします*1。 スライドはこちら アジェンダは以下の通りです。 導入 オブジェクトとは？ モデルとは？ ドメイン駆動設計とは？ まずは、ドメイン駆動設計のベースとなっている、「オブジェクト指向」や「モデル」について整理した上で、実際にドメイン駆動設計とはどういうものかを見ていき
DDD Sample Application - Introduction
Cargo freighter passing under the Golden Gate bridge in San Fransisco. Image courtesy of FreeFoto.com. One of the most requested aids to coming up to speed on DDD has been a running example application. Starting from a simple set of functions and a model based on the cargo example used in Eric Evans' book, we have built a running application with which to demonstrate a practical implementation of
[ 技術講座 ] Domain-Driven Designのエッセンス 第2回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第2回 DDDの基礎と実践 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 本連載は、全3回の予定でEric Evansの書籍『Domain-Driven Design』（以降DDD）を紹介しています。前回はDDDの概要を説明し、第I部「Putting the Domain Model to Work」からDDDの基本原則となる3つのパターンを紹介しました。今回は続く第II部と第III部から、（アンチパターンを1つ含む）16のDDDパタ
構造設計の良し悪し | システム設計日記
Domain-Driven Design(DDD)の１６章の最後の数ページは、パターンとして定義してないけど、構造設計について、興味深い内容が書かれている。 構造設計の良し悪しの判断？ ソフトウェアは、バグがあったり、性能問題が発覚すれば、開発チームのメンバーは、みんな問題だと思うし、修正しようと思う。 そして、直ったか直らないかは、いちおう確認できる。 構造設計になると、そうはいかない。 ソフトウェアがちゃんと動いていて、ソースの中身も、まあまあ、追いかけることができれば、全体の構造なんて、あまり気にしない技術者、チームが多いのかもしれない。 クラスが肥大化して、参照関係が入り組んできて、コードが読みにくくなり、修正の副作用が恐くなってくると、さすがに、これじゃまずい、という「感覚」はでてくる。 ファウラーが「リファクタリング」で書いているように「コードのいやな臭い」を感じる度合い、感じ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実践に向けたドメイン駆動設計のエッセンス
ドメイン駆動設計・俯瞰編・アプリケーション構築 - Strategic Choice
http://blogs.sun.com/nishigaya/entry/domain_driven_design_quickly
ドメイン駆動設計入門
