dddosaka 第11回での発表資料(2014年9月21日)
こんにちは。 @kimutyam (木村)です。 先日は『Scala/Scrum/DDD 困ったこと50連発ガトリングトーク』という勉強会にて登壇させていただきました。 scala-scrum-ddd-gatlingtalk.connpass.com 登壇後はガトリングすぎたのであっという間に終わったという意見がありましたので、 勉強会で質問していただいた内容の回答をまとめるエントリとします。 勉強会内容について Scala/Scrum/DDD 困ったこと50連発ガトリングトーク!! from Yasuyuki Sugitani www.slideshare.net 50連発でもスライド数173枚到達しました。 元々は100連発にしようと目論んでいたけど辞めてよかった... 以下のカテゴリで困ったことを50連発して各社でどのように解決してきたかというのが、このイベントの趣旨です。 詳細はス
Reactive Messaging Patterns読書会のなかで、「マイクロサービスとAkkaとGo」な面白い話題が出たので代表でまとめる試みエントリです。(結構、色々な話題に飛んでいるので難度高い。) まとめ方としては、会話ログを転記して、最後にまとめる形をとっています。また、議論と私の考えが混ざらないように所感は分けておきます。 ddd-cqrs-es.connpass.com TL;DR 要素技術(どんな言語使うとか、どんなアーキテクチャにするとか)の前に、組織やプロダクトの性格を考えて戦略を決めましょう。 そして、その中で最適と思われる戦術をとれるような要素技術を採用しましょう。 Akka良いよ。 ログ(一部抜粋) Slackからの引用のためテキストベースです。 事の始まりは、荒木さん(以下、 @applideveloper )の発言でした。 (この記事絡みですね。 集合知で各
経緯 casyというインターネットを使って手軽に家事代行を頼むことができるサービスのプログラマをしています。 Webだけでなく、スマホアプリも出すことにあたり、Webアプリサーバ(Rails)から機能を切り出し、APIサーバ(Rails)を別途作成し、Webアプリの場合はWebアプリサーバからAPIサーバを呼び出し、アプリからは直接APIサーバを呼び出すような仕組みにしました。 ただ、全部の機能をAPIサーバに移すのは容易なことではなかったため、いくつかの機能はまだWebアプリサーバに残っていて、アプリよりもWebのほうが機能が多い状態となっています。 今回残りの機能をAPIサーバに持ってくるにあたり、下記2つのアプローチがありました。 1. 既存のソースコードからViewを切り離してほぼそのまま持ってくる 2. 設計を見直し、大幅にリファクタする チーム内で議論した結果、スタートアップと
役割が明確な小さなオブジェクトに分けるのが、基本中の基本。 従業員を表現するために、従業員オブジェクトをルートとして、 ・個人 ・氏名 ・電話番号 ・生年月日 ・期間 ・給与 という小さなオブジェクトで構成する。 個人 氏名や電話番号のサブのルートクラス。 氏名 姓、名、セイ、メイを保持 バリデーションや、"姓名(セイメイ)"などのフォーマット出力を担当 電話番号 電話番号のバリデーションとか、フォーマット出力を担当 生年月日 生年月日を保持して、年齢計算も担当 期間 開始日と終了日を保持。 ある期間とある期間が重なっているかとか、期間演算を担当 給与 マネークラスのサブクラス。 将来は、給与計算ロジックを追加する場所。 --- オブジェクト指向の分析設計の発展形である、ドメイン駆動設計のオブジェクトの構成はこんな感じなる。 Evans の Domain-Driven Design のパタ
関西DDD.java 勉強会 2016-3-5 (DDD Alliance 勉強会 2016-1-21 @東京の京都再演版)
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
エリック・エヴァンスのドメイン駆動設計の本を一通り読んでみて、何かすっきりしない感想を持っていた。 @sakaba37さんや@jp_watanabeさんと議論して、すっきりしない原因がようやく分かったのでメモ。 ラフなメモ書き。 【元ネタ】 ドメイン駆動設計: プログラマの思索 ドメイン駆動設計よりもパターン本が好き: プログラマの思索 ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索 DOAとOOAの違い: プログラマの思索 Agile開発に足りないもの~モデリング技術: プログラマの思索 ドメイン駆動設計の本の違和感は二つある。 一つは、分析と設計を区別せず、設計中心の技法ばかり説明していること。 もう一つは、過去のオブジェクト指向設計との違いがはっきり理解できていなかったこと。 前者は、「ドメイン駆動設計」というタイトル通り「
Dynamic Data Displayは.NET向けのデータビジュアル化ライブラリです。地図へのマッピングもできます。 .NETアプリケーションなどでグラフやデータのビジュアル化に使えるライブラリがDynamic Data Displayです。多彩な表現が可能です。 デモです。これは世界地図です。マウスで移動したり拡大もできます。 等高線のような表示です。マウスがある場所と同じ高さが線で描かれます。 線が移動しているのが分かるでしょうか。 メルカトル図法の地図です。マウスのある場所が拡大表示されています。 カラーピッカーです。 リアルタイムにレンダリングされていくグラフです。 どんどん右に伸びていきます。 ヘルプです。グラフは画像として保存もできます。 Dynamic Data DisplayはSilverlightに用いることもできます。グラフとしては折れ線、バブルチャート、ヒートマッ
前回のエントリいまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味についてのブクマのコメントで、 すごく今さら感がw 最近の開発はフレームワーク使うことが多いようだから知らなくても作れちゃうと思ってたけど違うのかなあ。 という感想をいただきました。実際に、SI業界で多くの方々、特に、アプリケーション開発の下流工程を担当しない層の方でこのように考えている方はほんとうに多いのではないかと思います。確かに最近ではSalesforceなどの製品もありますし、CRUD処理を行うような見栄えの良い業務アプリケーションは非常に簡単に開発できるようになっているということはあります。また、Visual BasicやMS Accessなど気軽にアプリケーションを開発できるツール類は昔からありました。そして、業界構造などの理由からやむを得ない側面があるとはいえ、SIerの提供する多くの
引き続き、DDDの読書記録です。あまり詳しく書きすぎるとネタバレになって本が売れなくなってしまうといけないので、読んでいて特に気になったポイントにしぼって書いていこうと思います。 第1章とびら(PCBエンジニアとの会話、P7) 第1章の最初の部分でプログラマーである著者がプリント基盤設計のエンジニアとの会話と通して徐々にドメインの知識を吸収・咀嚼しながら、ドメインモデルを構築していくストーリーが語られています。 数年前、私はプリント基板(PCB: Printed-Circuit Board)設計用の専門ソフトウェアツールを設計することになった。しかし、1つ問題があった。私は電子機器について何も知らなかったのだ。もちろん、PCB設計者から話は聞けたが、彼らの話にはものの3分で頭がクラクラしてくるのが常だった。このソフトウェアを作成するのに十分なくらい電子機器について理解するには、どうすればよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く