DDDの思い出２つ - プロマネブログ
年度末になると宿題の駆け込み・年末の道路工事と同じく急な案件見積もりや技術調査依頼なんてのが入るもんで、すっかりまいっておりました。 こういうのももうちょい計画的にやってくれたら楽なのに。。。 上記のエントリ見て２つほど思い出したことがあったので。 ドメインを甘く見てはいけない 仕事をやっていると、外部公演や外部研修といった場で他企業でエンジニアやマネージャやっていた講師の話を聞くことがあります。 で、その場で出た話。 講師「まず、プロジェクトを進めるためには、プロジェクトマネジメントやアーキテクチャ、プログラミングと言った開発能力が必要となります。」 当方「それらが必要なことは理解しておりますが、業務知識・ドメイン知識はより重要ではないのですか？」 講師「業務知識はユーザがもてば良いもので、開発者はそこまで重視しなくても大丈夫です」 この話。ずーっとモヤモヤしてたのですよね。 なんだかん
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブ
DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
Modeling by Verb
セイコーエプソン株式会社、萩原豊隆さんによる、新しいモデリング手法、 「動詞de!! モデリング�」のプレゼンテーションです。 ・ソフトウェアの振る舞いは動詞で表現できます。しかし今までのモデリング手順では、“動詞”を適切に扱えませんでした。例えば名詞つまり目的語に着目する一方で、付随する動詞を無視して振る舞いを漏らす。あるいは「○○制御」クラスのように振る舞いがすべて“制御”という言葉に隠れてしまう。いずれも動詞の取り扱いのまずさに起因します。 ・そこで目的語と共に動詞も同時にクラス図へ変換する手法を作りました。モデリングツールを使って、目的語と動詞の組み合わせをサクサクとクラス図に変換していきます。クラス図の良し悪しは読み上げて確認です。単純かつ明快なので誰もがセンスに依存せずにモデリングできるようになります。Read less
ドメイン駆動設計のリファレンス本 | GuildWorks Blog
井上です。 現在、ドメイン駆動設計(Domain Driven Desing . 以下 DDD)を用いて開発を行っています。 DDDの参考書籍といえば、もちろん「エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう」(以下 DDD本)ですが、その著者であるエリック・エヴァンスが最近(2014/9/22)「Domain-Driven Design Reference: Definitions and Pattern Summaries」という新しい本(以下 DDDリファレンス本)を出していることに気がつきました。 DDDリファレンス本とは 早速DDDリファレンス本を取り寄せてみました。８８ページと非常にコンパクトな本になっています。 内容的には、以下で公開されているPDFに新しい図や写真を追加してペーパーバックとして出版したもののようです。 DDD REFERE
JSUG 20141127 「Spring Bootを用いたドメイン駆動設計」
第1回 しょぼべん ( http://connpass.com/event/10849/ ) で話しした、イミュータブルデータモデル(世代編)です。
「開発しない」という越境 #DevLOVE - assertInstanceOf('Engineer', $a_suenami)
このエントリは DevLOVE Advent Calendar 2014 「越境」 の5日目です。 つい先日申し込んだのに予想外に早くバトンがまわってきました。笑 前日は @azumi さんの「【マンガ】旅行サービス開発のデザイン現場へ。種を持ち帰る『越境』の旅」でした。まさかマンガとは！笑（楽しく読ませていただきました。） @azumi さんは産業技術科学大学の人間中心設計プログラムにいらっしゃるのですね。弊社の社員も現在通っていて、一緒に学んでいるようです。 さて、僕は昨年に引き続き今年も DevLOVE Advent Calendar に参加させていただきます。 昨年のエントリはこちら。 現場の反対はまた別の現場 #DevLOVE - assertInstanceOf('Engineer', $a_suenami) 自己紹介 すえなみと申します。漢字で書くと末並です。「末波」とよく間
@kawakawaさんの「C＃実装から見るDDD」資料が素晴らしい #dddosaka - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
【公開】第11回ドメイン駆動設計勉強会の発表資料「ドメイン駆動設計で気づいたこと～権利の概念とERP分析への適用」 #dddosaka - プログラマの思索
【公開】第11回ドメイン駆動設計勉強会の発表資料「ドメイン駆動設計で気づいたこと～権利の概念とERP分析への適用」 #dddosaka 第10回ドメイン駆動設計勉強会の感想 #dddosaka: プログラマの思索 第7回ドメイン駆動設計勉強会の感想 #dddosaka: プログラマの思索 第6回ドメイン駆動設計読書会の感想: プログラマの思索 第４回ドメイン駆動設計読書会の感想: プログラマの思索 オブジェクト指向設計の４つの流派からドメイン駆動設計へ: プログラマの思索 [ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場 [ 技術講座 ] Domain-Driven Designのエッセンス 第2回｜オブジェクトの広場 [ 技術講座 ] Domain-Driven Designのエッセンス 第3回｜オブジェクトの広場 【1】DDD読書会@大
C＃実装から見るDDD(ドメイン駆動設計)
わんくま同盟勉強会@大阪＃６０でお話しさせて頂きました。 『C＃実装から見るDDD(ドメイン駆動設計)』を多少手直しをして、再掲載しました。Read less
ドメインモデルの育て方
BPStudy #82 2014/6/27 ギルドワークス「正しいものを正しくつくる」、市谷さんとの合体発表。 ドメイン駆動設計。Read less
ユースケース駆動開発実践ガイドを読んでわかったこと - paz3のおもいつき
ユースケース駆動開発実践ガイド を読んでいます。現在、ロバストネス分析のところまで読み進めました。この本で目からウロコが落ちる体験をしています。以下、気付いた点です。 ユースケースってすごい いままでユースケース記述というのは「アクターと丸をつないだものに、他の資料（機能仕様書など）から見つけ出した説明をつけたもの」で「あまり役に立たないもの」と考えていたのですが、違いました。ICONIXプロセスでは次のことをすることで、ユースケースを設計の基本となる極めて重要な資料に仕立て上げています。 先に用語リスト（ドメインモデル）を作成し、そこに含まれる用語を使うことで曖昧さを排除する。 宣言的（例：ユーザーは検索できる）ではなく叙述的（例：ユーザーは検索ボタンをクリックする）に書く。 「事前条件」「アクター」「スコープ」「レベル」「成功時保障」などの項目を省略し、その分、モデリングに集中する。
ユースケース駆動開発実践ガイドを読んでわかったこと、その2 - paz3のおもいつき
ユースケース駆動開発実践ガイド を読んで気付いたことのメモです（そんなの当たり前だよ！」というようなこともあるかもしれませんが、ご容赦ください）。前回（d:id:paz3:20090613）の続きです。 シーケンス図のメッセージとロバストネス図のコントローラは1対1対応しなくてもよい 最初、ロバストネス図のすべてのコントローラをシーケンス図のメッセージに置き換えようとしました。たとえば「数量が足りていれば○○する」というような判断をするコントローラも、とあるオブジェクトの自分宛のメッセージとして記述しました。その結果、メッセージ（メソッド）の数が膨れ上がり、わけがわからなくなってしまいました。 書籍を読み直してみたところ、次のように書いてありました。 コントローラと操作の間に1対1の対応を取る必要はありません シーケンス図上にフローチャートを描こうとしてはいけません そこで、シーケンス図か
DDDとはこういうことなのか - Some Days You Get the Bear
♪今年のブクマ、今年のう・ち・に！ ← 書いてるうちに年こしちゃったね というわけで、もうひとつの ”長くてほったらかしだったやつ” を読む。 ドメイン駆動設計入門 - Digital Romanticism 正直これまでドメイン駆動設計って「言葉を知っている」という程度のものだったのですが、 この和智さんのブログを読んで、もうちょっとは先に進むことができた感じがしました。 以下に、私が今回理解できた部分を抽出して、少しでもコンパクトにすべく、ショートバージョンとして抜粋してみます。 ■オブジェクトとは？ 大げさな表現をすれば、「僕らは言葉によって世界を切り分け、そこに名前を与え、意味に囲まれて生きている」ということですね。あるモノに意味を見出し、他のモノと切り分け、そこに名前を与えることで自分たちの世界を構築しているのが人間だ、ということです。オブジェクト指向において、オブジェ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DDD関連書籍メモ - Qiita
ゆらぎのある決定
Base DDD(ドメイン駆動設計） 参考文献を巡る旅
Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」
Dddをもっと身近に
https://github.com/terasolunaorg/terasoluna-tourreservation/tree/master/terasoluna-tourreservation-domain
