[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
OOエンジニアの輪！ 〜 第 34 回 比嘉 康雄 さんの巻 〜
特になし。 私は人を丸ごと尊敬することはありません。それぞれ好きなところもあれば、嫌いなところもある。できるだけいろんな人の素敵な点を見つけて、その素敵な点を 認識したいです。 現在のお仕事について -- まず最初に、現在の業務についてお話していただけますか？ 弊社でこの 4 月より「Seasar2 技術推進グループ」が新しくできました。そこで主に、弊社の中での Seasar2 を使ったプロジェクトへの支援や、商用サポートなどをやっています。 あるいは、ちょっと会社の仕事には関係ないんですけど、Seasar プロダクトの強化もやっています。 -- 基本的には技術的なリーダーをされているのでしょうか？それともマネジメントが中心ですか？ 時と場合によりけりで、会社ではマネジメントとして判断することがほとんどです。 Seasar ファウンデーションではチーフコミッターとしての役割がありますので、
マイルドなアジャイル開発手法 AMOP | オブジェクトの広場
今回は, アジャイルモデリングを実践するためのベースとなるアジャイル開発手法として筆者らが考案したAMOP (Agile Method for Ordinary Projects) [1] という開発手法を紹介します. AMOP は, 既存の開発のやり方に慣れた開発者や管理者に受け入れられやすいものであることを目指したアジャイル開発手法です. 今回の記事では, まずスクラム [2] の短所や難しい点を説明し, 次いでそれらを XP (eXtreme Programming) [3] のプラクティスでどのように補おうとしたかについて説明します. さらに, AMOP を２つのプロジェクトに適用した結果を紹介します. 1. スクラムの短所や難しさ 前回の記事では, もっともシンプルで取り入れやすいと筆者が考えるアジャイル開発手法スクラムを紹介しました. その記事では, スクラムの長所を中心に説明
スクラム組んで開発しよう！ | オブジェクトの広場
今回の記事では, プロジェクト管理に特化したアジャイル開発手法であるスクラムの概要を説明します. また, スクラムによる開発が成功する理由を説明するための理論的なバックボーンとして引用されている知識創造プロセスやコンテキストの概要を紹介します. さらに, 20 名程度の中規模開発チームにおいてスクラムを適用し, 開発に成功した事例を紹介し, その中で知識創造プロセスやコンテキストが生まれたのか否かについて考察します. 1. スクラムとは 1.1 スクラムの価値と理論的な基盤 スクラム [1] は, Ken Schwaber と Mike Beedle によって考案されたアジャイル開発手法です. スクラムという開発方法論の名称は, ラグビーのスクラムにちなんで名づけられたそうです. スクラムは、Schwaber らがいくつかの失敗プロジェクトを立て直す経験を通じて生み出されたとされています.
設計におけるオブジェクトの責務分配に有効なものさし -凝集度と結合度- | オブジェクトの広場
1. はじめに 皆さん、こんにちは。私はオージス総研でオブジェクト指向技術を用いたSI、コンサルティングを業務とする、プロの仕事を目指す、一介のUMLシルバーレベル1のプログラマ2です。ソフトウェア業界では、オブジェクト指向も、もはや普通の技術として認知されています。有名なマイクロソフトのVB、VC++をはじめ、現在使用している開発環境のほとんどは、すべてオブジェクト指向をサポートしているといってもよいでしょう。オブジェクト指向を知らない人でも、気が付かないうちにオブジェクト指向している、なんてこともあるようです。 でもオブジェクト指向は、単にソフトウェアをより良く作るための手段のひとつですから、上手く利用しないと、そうするつもりはなくても、とんでもないソフトウェアを作ってしまうことになりかねません。悲しいことに、オブジェクト指向は結構敷居が高いと思います。オブジェクト指向のメリットである
オブジェクトの広場編集員が贈る勘違い集
［特別企画］ オブジェクトの広場編集員が贈る勘違い集 仕事や日常生活に勘違いはつきものです。 特に技術的な内容の勘違いは、自分一人ではなかなか気づかないもので、 あるとき先輩に指摘してもらったり、別件のことを詳しく調べてたりするときにふと発見することが多いでしょう。 本記事では、そのような自分一人では気づきにくい技術的な内容の勘違いを、オブジェクトの広場編集員の実体験に基づいて集めてみました。 オブジェクト指向に関係する技術的な内容の勘違いとして、大きく 「オブジェクト指向開発における勘違い」、「UML の表記における勘違い」の 2 つに分類しています。 また、番外編として「日常生活における勘違い」も集めてみました。技術的な内容に疲れたときにでもお楽しみください。 なお、取り上げた勘違いの中には、まだ勘違いしているところもあるかと思います。もし、その点をお気づきになられた方はオブジェクトの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
