『技術プレゼンのための10のTIPS』
※ この記事は、Ross Mason氏（MuleSource CTO）の記事「Ten Tips for Technical Presentations」を本人の許可を得て翻訳したものです。 ----- 今日は、マルタ島で開催されたSunオープンソースデイのモーニングセッションに参加した。セッションの質には、たいへん失望した。こういったイベントには時間も金もかかっている訳で、質の悪いセッションを見せられるのは百害あって一利なしだ。今日はSunにとっても、得るものは何もなかったと思う。 私が長年にわたって集めてきたTIPSを、紹介したいと思う。このTIPSのおかげで、これまで私の技術プレゼンを聴いてくれた人によりよい体験を提供してこれたと思っている。 自分が誰なのかと、これから何をプレゼンするのかを必ず紹介すること。今日は4つのプレゼンを見たが、1人しかこれをやっていなかった。聴き手は、誰がし
『DIコンテナとドメインモデルの相性の悪さ』
Seasar、SpringなどのDIコンテナを使っていると、ドメイン層の実装はデータ（Entity／Dto）と振る舞い（Service／Logic）に分ける、いわゆるトランザクションスクリプトのスタイルになりがちだ（参照(1)、(2)）。理由は、1つにはドメインモデルの設計／実装そのものの敷居が高いこともあるが、そのハードルを乗り越えても、DIコンテナそのものがドメインモデルと馴染みにくい側面があるからだと思われる。 DIコンテナはエンティティやDTOにDIできない その側面とは、次の通り。DIコンテナは設計思想からしてファクトリの役目をするものであるため、DIコンテナを使う場合、インスタンスの生成は基本的にDIコンテナが担当することになり、コンポーネントに必要なオブジェクトはすべてDIで渡されるような設計に誘導されてしまう DIを使ったWebアプリケーションのアーキテクチャは、まずリクエ
『[お知らせ] S2DomainModel リリース』
S2DomainModel 0.1をリリースしました。S2DomainModelは、Seasar2でドメインモデルやDDDの実装をサポートするためのライブラリです。 http://ouobpo.sourceforge.net/s2domainmodel/ 前回のエントリ「DIコンテナとドメインモデルの相性の悪さ」で書いたとおり、ドメインモデルの中で直接生成されるドメインオブジェクト（= Entity + Logic）に他のオブジェクトをDIすることは設計上難しく、ドメインモデルの自由な設計が阻害されてしまいます。そのため、DIコンテナを使った開発では、リッチなドメインモデルは敬遠されがちです。 S2DomainModelは、この相性問題を解決するためのライブラリです。ドメインオブジェクトにDIできる仕組みを提供することで、DIコンテナを使った、より自由なドメインモデル構築を可能にします。
『ドメインロジックの実装方法とドメイン駆動設計』
以前一緒にお仕事をさせていただいたこともある、ビープラウドの佐藤治夫さんが主催の勉強会BPStudy 第7回にて、発表の機会をいただいたので話してきました。発表テーマは「ドメインロジックの実装方法とドメイン駆動設計」です。 http://www.beproud.jp/bpstudy/17/bp-study-7 後ほどBPStudy勉強会のサイトでも発表資料が公開されると思いますが、こちらにもUPしておきます。（アメブロではSlideShareやhandsOutのスライドを直接貼れないようなので、ちょっと変な貼り方をしています） http://handsout.jp/slide/371 以下の二部構成でお話ししました。Ⅰ. ドメインロジックの実装方法 Ⅱ. ドメイン駆動設計の紹介 前半は、お馴染みの「トランザクションスクリプト vs. ドメインモデル」の話です。それぞれのサンプルコードを交え
『DDDについての覚書』
少し前のことだが、.Net Rocks! というオンライントークショーのサイトに『Domain-Driven Design』の著者Eric Evansのインタビューが上がっていたので、今になってiPodに入れて通勤の行き帰りに聴いている。 http://www.dotnetrocks.com/default.aspx?showNum=236 インタビューの中で非常に印象的だったポイントを2つ、覚書として書いておきたい。 - DDDだからといって、全部ドメインモデルで構築するものだと思い込むのは間違い - 重要なのは、開発手法としてのアジャイルではなくて、ビジネス本来のアジャイルさ（変化のスピード）についていくこと Martin Fowler, Eric EvansDomain-Driven Design: Tackling Complexity in the Heart of Softwa
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
