はてなブログ | 無料ブログを作成しよう週報 2024/04/28 川はただ流れている 4/20（土） 初期値依存性 さいきん土曜日は寝てばかり。平日で何か消耗しているらしい。やったことと言えば庭いじりと読書くらい。 ベランダの大改造をした。 サンドイッチ 一年前に引っ越してからこんな配置だったのだけど、さいきん鉢を増やしたら洗濯担当大臣の妻氏…
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の本だったのですが、サイン入りということでますます真剣に読書に取り組みたいという気がしてきました。今後日本語版を用いた勉強会も計画されているみたいですが、とりあえず、章ごとに読書記録をつけていきたいと思います。
ドメイン駆動設計入門 - Digital Romanticism
"Beautiful Develpment"（10/27 DevLOVE）の講演資料と原稿 はじめに 本日（10/27）、DevLOVE様主催で、"Beautiful Develoment"と題されたイベントが開催されました。これは「ドメイン駆動設計（"DDD:Domain-Driven Design"）」を題材に、入門から実践までを語り尽くすというコンセプトのものです。このイベントにおける講演のトップバッターとして、ドメイン駆動設計の根底にある基本的な考え方についてお話しさせて頂きましたので、講演資料と原稿を公開いたします*1。 スライドはこちら アジェンダは以下の通りです。 導入 オブジェクトとは？ モデルとは？ ドメイン駆動設計とは？ まずは、ドメイン駆動設計のベースとなっている、「オブジェクト指向」や「モデル」について整理した上で、実際にドメイン駆動設計とはどういうものかを見ていき
相互依存性の設計・実装パターン いろいろ | システム設計日記
Repository パターンを書いた記事で、「相互依存性」について興味深いコメントをいただきました。 現実の業務アプリでぶつかる、とても重要な設計課題だと思います。 私なりの、やり方のアイデアをざっと整理してみました。 コメントいただいた内容（抜粋） > でも、「ビジネスパターンによるモデル駆動設計」にある経済減少イベントと経済増加イベントのように対等なエンティティでは、相互依存関係をどのように解決すればいいのかわかっていません。業務要件上はこの2種類のエンティティは区別されなければならないので、困ったもんだなーとｗ > BusinessIncrementRepositry > BusinessDecrementRepositry > なるものを作っても、相互依存関係は解消されないなーと。 > こういう場合の何かよいアイデアとかお持ちではないでしょうか？ 「ビジネスパターンによるモデル駆
[ 技術講座 ] 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）は、「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://books.shoeisha.co.jp/book/b82520.html