さて、4月からこのBLOGを書いていますが、プログラマーズログと銘打っているのにこの記事が初めての技術系の記事ですw なぜ唐突に技術系の記事を書き始めたのかというと、ダジャレクラウドの使用技術が JAX-RS(RestEasy) Google App Engine/Java Slim3 Twitter4J jQuery という技術を使っているので、これら周辺の技術を身につけたいIT技術者も結構いるんじゃないかと考え、ダジャレクラウドの実装で得た知識をベースにした実践的な勉強会を開こうかと企画しているからです。 とりあえずは、技術者向けでなく自分でWebサービスを立ち上げたいが、フロントエンドはともかくとしてバックエンドがよくわからないWebデザイナーやイラストレータだけどWeb系の知識をつけたい人のようなグラフィック系のスキルを持った人を対象に基礎的な講座を開こうかと思っています。グラフィ
About 南の島のプログラマ。 たまに役者。 Practical Schemeの主。 WiLiKi:Shiro 最近のエントリ 米国の大学進学無限cxr高校受験Defense振り返ってみると2019年は色々学んで楽...覚えるより忘れる方が難しい(こともある)眼鏡のつると3DプリンタIris Klein Acting ClassSAG-AFTRA conservatory: Voice Acting創作活動って自分を晒け出さねばならないと...More... 最近のコメント Jessica Kirkpatrick on CLtL2 (2025/06/28)shiro on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/14)1357 on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/01)ベアトリーチェ on ハイポハ
"Beautiful Development"（2011.04.09 DevLOVE）の講演資料と原稿 はじめに 本日（4/9）、DevLove様と共同で、第２回"Beautiful Development"を開催致しました。これは、日本語版DDDの発売を記念し、DDDに造詣の深い方々に集まって頂き、２枠構成で講演して頂くという豪華なものでした。このカンファレンスでトリを務めさせて頂きましたので、講演資料と原稿を公開致します*1。なお、今回の発表は「ドメイン駆動設計入門」では駆け足でまとめてしまった部分を、改めてクローズアップした続編と考えて頂くこともできるでしょう。 アジェンダはこちら 戦略的設計とは？ サンプル業務 モデル駆動設計をすると？ 戦略的設計 スライドはこちら 戦略的設計とは？ 「戦略的設計（Strategic Design）」とは、DDD第４部のタイトルです。DDDは全体で
オブジェクト指向は、人によって理解が違って、それを上手く共有出来ないと凄い認識違いが起きたりするので、ここで自分の考え方をまとめてます。 ここでいうオブジェクト指向は、クラスベースのオブジェクト指向のことです。 制限と拡張 オブジェクト指向は、それまで出来ていたことに対する制限とそれまで出来なかったことという拡張の２つの側面があります。 制限 カプセル化（※1） 言語仕様として、公開範囲を決められる 拡張 ポリモーフィズム 継承やインタフェースを用いる事により、様々なテクニックが使える この２つは、全くの別の概念として説明されることが多いですが、どちらも「相手に必要な情報しか渡さない」と考える事が出来ます。 カプセル化 相手に必要ない「内部構造と実装」を隠蔽する ポリモーフィズム 相手に必要ない「必要としてる型以外の情報」を隠蔽する これを確認するために、オブジェクト指向が出来るまでの流れ
Aws Dev Day2021 「ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキル」参考資料(松岡パート)
DCI (data context interaction)
DCI アーキテクチャという設計についての考え方がある。数年前から scala 界隈で盛り上がっていた記憶があるが、最近は ruby/rails 界隈でも盛り上がっている模様。 先日の札幌 ruby 会議で角谷氏が発表を行っている。 rubykaigi http://sapporo.rubykaigi.org/2012/ja/schedule/details/79.html スライド http://kakutani.com/20120916.html#p01 そこからたどって以下のような資料があるのも発見した。 objects on rails （書籍の無料公開) http://objectsonrails.com/ Clean Ruby http://clean-ruby.com/ 書籍サイト。ベータ版書籍が購入可能。$42なので電子書籍にしてはかなり高い。 DCIの講演 tog
DCIを参照しつつ「業務分析」について考える はじめに 最近「アジャイル」という言葉をなるべく使わないようにしています。なぜなら、この言葉に込められた「桃源郷へのあこがれ」が、色々なものを見えなくしてしまうような気がするから*1。例を挙げましょう。アジャイルの基本は、「タイムボクシングによるインクリメンタルかつイテレーティブな開発」であると言え、それを実現するために流派によって様々なテクニックが提示されます。Scrumを見てみましょう。Scrumを実現するために絶対的に必要なのは、プロダクトオーナーによって適切に優先順位付けされたプロダクトバックログなわけですが、網羅性と整合性を保証したかたちでバックログアイテムを優先度順に並べるって、実はものすごく難しいことを言っていませんか？ 確かにタイムボクシングによる軌道修正がある程度できるとは言え、「優先順位の低いところは粒度が粗くてもいいよ」で
初期のドメインモデリングは、システムの全体像のデッサンに不可欠な実践のひとつ。 「どんな情報を扱うシステムか」という「情報の視点」を中心にして、機能と並行性を視野に入れて、システムの全体像を、Ａ４一枚のクラス図にまとめていく。 「概念モデリング」とか、「業務の用語集作成」とほぼ同じ。 業務で扱う情報名や業務上の処理（機能）名を、クラス図として描いていく。 光源はドメイン UMLツールでクラス図を書くと、それぞれのクラスは、線の太さや色が同じになる。 これだと、かなり平坦なデッサンになり、あまり役に立たない。 ドメイン、つまり、業務の視点、業務から見た重要度や、関心の強さを光源にして、強く光る部分、弱く光る部分、陰影などを描きこめば、モデルが、立体的に、生き生きとしてくる。 ドメインという光源から、陰影や強弱をつけた絵は、関係者の認識合わせに、とても役にたつ。 線の色も太さも同じ四角がならん
コップ本といい、DDD本といい、最近鈍器系の本づいてます。仕事のピークが重なっていたので、会社の行き帰りの電車の中か昼休みにしか読む時間が取れず、読み切るまでに非常に時間がかかってしまいました(3ヶ月以上かな？)。 副題にある通り、開発者がユーザとともに複雑さに対峙するための方法を(問題を切り分けよう、とかそういうお題目レベルではなく)実際の設計プロセスやパターンにまで落とし込んでいて、実践的であり具体的です。パターンそのもの以外にも、著者の経験に基づく設計現場のサンプル(開発者とユーザの対話とそれに伴うモデルの変化)が豊富で、パターンだけだとわかりづらくなる箇所を捕捉してくれています*1。しかも、理論ばかりの設計方式ではなく、ちゃんと実装とビジネスをモデルでつなぐための方法であるというのもすばらしいです。ってか、技術を知らずに設計ができると思っているご用聞きSEさんは遠慮なく死んで下さい
"Domain-Driven Design"におけるドメインモデルの性質について簡単にふりかえった上で、そのドメインモデルが位置づけられる領域について整理する。 導入：ドメインモデルとは DDDにおける主要な主張は、ソフトウェアが対象とする領域（ドメイン）についてのモデリングを正確に行った上で、それをソースコードにおいて表現するというものでした。ドメインモデルとはつまり「ドメインについてのモデル」なのですが、これは実体としてアプリオリに存在するものではなく、「現実を解釈することによって、目の前の問題を解決する上で重要となる側面を抽象化したもの」（p.2）、あるいは「ドメインエキスパートの知識が厳格に組織され、選択的に抽象化されたもの」（p.3）とされてます。つまり、現実世界を写し取ったものではなく、ある特定の視点に基づいて世界を切り取ったものである、ということですね。もちろん、ここで言われ
あけましておめでとうございます。 去年の暮からエリック・エヴァンスのドメイン駆動設計という5200円、500ページもする本を購入して読み始めた自分です。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (129件) を見るあまりに勿体無かったので試しにこのドメイン駆動設計の設計思想にそって、簡単なアプリをSymfony2で作ってみました。 実際に作られたサイトは、 http://www.soichiro.org/sf こんな感じです。 id: [email protected] pass: test1 でログインできます。(ユーザー作るだけなら
Domain-Driven Design(DDD)の１０章 "Supple Design (しなやかな設計)"は、この本の中では、ちょっとかわった章です。 この章だけは、 ・開発者の視点で ・開発者のための良い設計 にフォーカスしている。 業務の専門家にとってどうか、とか、ソフトウェアの利用者にとってどうか、という議論はまったくでてこない。 ある意味、ドメイン駆動設計らしくない章になっている。 （もちろん、開発者にとっては、面白いし、参考になる内容ばかり） 良い設計ってなんだ 良いソフトウェアは、利用者にとって役立つこと。 でも、この章では、良いソフトウェアのもう一つの側面、「開発者にとって良いソフトウェア、良い設計」に焦点をあてている。 キャッチフレーズは、 "a design that is a pleasure to work with" ふれるのが楽しくなるコード、という感じですか
ドメイン駆動設計(DDD)の Value Objects パターンでは、オブジェクトを不変(immutable)にすることを強く推奨している。 なんとなく、そんなもんか、と思っていたけど、ある日、なるほど、というケースに出くわした話し。 変数名にこだわる 前提として、変数名にこだわるようになったことがある。 DDD のユビキタス言語パターンの実践として、 ・パッケージ名 ・クラス名 ・メソッド名 ・変数名 は、業務上の意味のある名前にこだわることを、徹底しはじめた。 Java Calendar クラスの日付計算 当日から、２週間後に、期限切れになる、というビジネスルルールを実装していた。 Calendar getExpireDate() { Calendar now = Calendar.getInstance(); now.add( Calendar.DATE, 7*2 ); retur
レッツゴーデベロッパー2011での発表原稿とスライド 導入 2011年05月28日「レッツゴーデベロッパー2011@仙台」が開催されました。このイベントのテーマは「共有と交流」。"「共有」には、最新技術、知識、復興への想い、それぞれの決意を共有することを、「交流」には、東北と東北圏外のデベロッパーやコミュニティ同士の交流を深めることを込めて。" このイベントにてDDDセッションに登壇させて頂きましたので、そのときの発表原稿とスライドを公開致します。なお、当日はワークとして参加者の方にペアモデリングを行って頂きましたが、このドラフトではその部分を割愛しています。 スライドはこちら また映像はこちらで公開して頂いています。 さて今年4/9にDDD日本語版が出版されました。それから２ヶ月弱、翔泳社様から、はやくも増刷のお知らせを頂きました。多くの方々とおかげと深く感謝しています。さて、この増刷が
Jan 4 2014Tags: dci ddd 昨年末にだらだらDCIに関する自分の考えを整理したくて身内で話していて、 結論としては「DDDとDCIどちらもメンタルモデルに近づけるために機能してる点は変わらない。その先DDDあるいはDCIをフレームワークにするか、あるいは一部に取り入れるのか、そこは取組むドメインによって取捨選択だよね」というところに落ち着いたのだけれど、勿体無い内容な気がするので改めてブログに書くことにする。 DDD脳から見たDCIの考察 DCIはFATなドメインモデルに対するアプローチというよりは、シナリオを明確にするためのアプローチなのかなと思う。 DDDを実践するような複雑な問題に直面した時、ドメインモデルは山のように増える。より知識を噛み砕いてドメインモデルにしたほうがより上層のロジックが簡潔になるので積極的にドメインモデルに落とし込む方がよく、結果として、シナ
ビジネスとソフトウェアの統合という観点から、スクラムとドメイン駆動設計の関係をとらえなおす。 導入 ここ数ヶ月は日本のスクラムにとって、おそらく非常に有意義な期間だったのではないかと思います。12月にJim Coplien氏による認定スクラムマスター研修、１月にGabrielle Benefield氏とJeff Sutherland博士による認定プロダクトオーナー研修が開催され、さらにInnovation Sprint 2011では野中先生とSutherland博士の対談までもが行われました。私は幸運なことに、これらのイベントにはすべて参加することができたのですが、そうやって学ぶことができた今では、スクラムのことを、一言で言うと「価値の流れを生み出すためのフレームワーク」ではないかというイメージを持っています*1。「フィードバック」や「改善」など、スクラムにとって重要な概念はいくつかありま
６月２３日（土）午後、大阪で、ドメイン駆動設計について、しゃべる予定。 第47回 SEA関西プロセス分科会のご案内 紹介の紹介の紹介、みたいな不思議なつながりで、講演の依頼があった。 「ドメイン駆動設計」を監訳された今関さんも参加いただける。 土曜の午後なので、時間が多め。 一方的にしゃべって終わりではなく、今関さんも交え参加者で、いろいろ話す時間を一時間以上とってもらいました（さらに懇親会もゆっくりと）。とても楽しみなイベントです。 ドメイン駆動設計は、訳本がでてから、あちこちで勉強会や読書会が開かれているようだし、ドメイン駆動設計に興味持ったり、現場で取り組む人が、すごく増えた気がしている。 ネットで流れる情報も「ドメイン駆動ってなんぞや？」的なものだけでなく「私は、こう理解している、やっている」的なものが多くなったんじゃないかなあ。 訳本の威力は絶大。 さて、講演の準備は、いつものよ
ドメイン駆動設計の実践に向けて、DDD本では明示的に語られていない視点からドメイン駆動設計をとらえ直す。 導入 ドメイン駆動設計入門では、かなり抽象的なレベルでDDD本の根底にある思想を概観しました。一言で要約すれば「ドメインエキスパートの頭の中にあるドメインをとらえるモデルを共有し、オブジェクト指向のパラダイムを用いて、それをソフトウェアの実装に落とし込む」という構想であると言えるでしょう。これを踏まえて今回は、実践のためには何が必要なのか、という問題意識からドメイン駆動設計をとらえ直してみたいと思います。 今回のポイントはプロセスです。DDD本ではほのめかされているにすぎない「モデリングのために行われているもの」に焦点を合わせて、設計とプロセスをどのように融合させていけばよいのかを考えていきたいと思います。ここでの目的はDDD本を批判することではなく、語られない点からとらえ直すことで、
先日、DevLOVEで発表した「コードで学ぶドメイン駆動設計入門」ですが、入門としながらも難しかったかもしれません。モデリングの話は難しい方の話題なので仕方ないのですが、できるだけわかりやすく補足するブログを書いてみたいと思います。 まず、レイヤードアーキテクチャの話ですが、こちらのスライドを参照してください。 DEVLOVE HangarFlight で話したスライド&ソースコード - じゅんいち☆かとうの技術日誌 平たく言うと、そのアプリケーションが解決する問題の領域がドメインです。ドメインとそれ以外のものをごっちゃにしないようにしたのが、ドメイン駆動設計だと考えればよいと思います。 一般的に業務システムでは、対象業務がドメインに成り得ますので、ドメインは業務に準えて語られることが多いと思います。ドメインに登場する概念をユビキタス言語*1として定義し、モデルに落としこむというのが設計の
珍しく日記が続いています 何をやらせても3日と続きやしない私がブログを3日連続で書いている時点で、空からヤリが降ってもおかしくないこの年度末、皆様いかがお過ごしでしょうか。 最近すっかり拙著ネタばっかりになってしまいましたが、急に「昨日はengine.ioいじって挫折してました」とか書いても話題が飛びすぎるので、書籍つながりでドメイン駆動設計(DDD)について個人的な意見を書いてみたいと思います。 ドメイン駆動設計(Domain Driven Design) 一部の方には釈迦に説法になってしまうかもしれませんが... ドメイン駆動設計（英: Domain-driven design, DDD）とはソフトウェアの設計手法であり、 '複雑なドメインの設計はモデルベースで行うべきであり'、 'また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
