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コミュニティーに貢献したりしていないと参加してはいけないのでないかと
DDDの読書記録（第3章、モデルと実装を結びつける） - 達人プログラマーを目指して
DDDの第3章では、モデルと実装との結びつきについて書かれていますが、この章はこの本の中でも私のもっともお気に入りの内容が書かれている章の一つです。従来、モデルやモデル駆動というと、コーディングとは対極にあるもの、アジャイルの思想と相容れないものというという考えもありましたが、DDDではプログラマーによるコーディング作業をモデリングの最重要の活動の一つと考えていることがこの章にはっきりと記述されています。 コーディング作業と設計の強い結びつきの必要性については以前から自分自身の体験を通して漠然と感じてきたことですし、そのことについては、プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指してでも書いた通りです。このエントリーは今のところ私のブログで最高のブクマ数をいただいたエントリーとなっているのですが、プログラミングと設計との結びつきについては実際に（賛否両論を
DDDの読書記録（第2章、コミュニケーションと言語の使い方） - 達人プログラマーを目指して
アジャイルプロセスのXPでもコミュニケーションに重点が置かれますが、その考え方に影響を受けているDDDでも業務担当者とプログラマーとの間のコミュニケーションを重視しているようです。しかし、これは「報連相」「根回し」「場の空気を読む」といった、いわゆる業界の新人研修やOJTで先輩社員から叩き込まれるような人間的なコミュニケーションのことよりは、むしろ、共通の言語やモデルによる科学的なコミュニケーションという点に重点を置いています。もちろん、最終的にコミュニケーションは人間同士で行うものなので、ヒューマンスキルが重要なのは言うまでもないことですが、日本の場合伝統的にチームの和を乱さないとか事なかれ主義のようなところもあり、事実に基づく正直なコミュニケーションが良くないとされるケースが多いようです。つまり、エンジニアとしてよりもむしろ、サラリーマンとしてのコミュニケーション能力が重視されるという
DDDの読書記録（第1章、知識のかみ砕き） - 達人プログラマーを目指して
引き続き、DDDの読書記録です。あまり詳しく書きすぎるとネタバレになって本が売れなくなってしまうといけないので、読んでいて特に気になったポイントにしぼって書いていこうと思います。 第１章とびら（PCBエンジニアとの会話、P7） 第1章の最初の部分でプログラマーである著者がプリント基盤設計のエンジニアとの会話と通して徐々にドメインの知識を吸収・咀嚼しながら、ドメインモデルを構築していくストーリーが語られています。 数年前、私はプリント基板（PCB: Printed-Circuit Board）設計用の専門ソフトウェアツールを設計することになった。しかし、１つ問題があった。私は電子機器について何も知らなかったのだ。もちろん、PCB設計者から話は聞けたが、彼らの話にはものの３分で頭がクラクラしてくるのが常だった。このソフトウェアを作成するのに十分なくらい電子機器について理解するには、どうすればよ
DDDの読書記録（第1部序章、ドメインモデルを機能させる） - 達人プログラマーを目指して
先日開催されたQCon Tokyoにて、翔泳社さんのブースでエリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)をTシャツ付きで購入しました。そして、Twitterにて翔泳社の岩切さんと というやり取りがあったのですが、結局、ご好意で急遽サイン会を開催していただけることになりました。 それで、原著者のエヴァンスさんと翻訳者の一人である和智さんのサインをいただくことができました。本当に感激です、ありがとうございました。（ご愛嬌で和智さんのサイン日が11日になっていますが、実際は12日です。） ということで、もともと大好きなDDDの本だったのですが、サイン入りということでますます真剣に読書に取り組みたいという気がしてきました。今後日本語版を用いた勉強会も計画されているみたいですが、とりあえず、章ごとに読書記録をつけていきたいと思います。
システム系の例外は実行時例外＋AOPでハンドリングするのがベスト - 達人プログラマーを目指して
インフラ層のチェック例外はやはりJavaのBad Partだと思う 先日のJava言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指してで、 インフラ層のフレームワークなどでは実行時例外が適切 ということを書いたのですが、この点についてもう少し詳しく考えてみたいと思います。 Java: The Good Partsの本ではRMIの章があるのですが、RMIではRemoteというマーカーインターフェースを継承しつつ、すべてのメソッドがRemoteExceptionというチェック例外を送出する規則となっています。 Java Good Parts（9.1節より引用） pubic interface StatRecorder extends Remote { void recordGame(BoxScore stats) throws RemoteException;
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
