DDD失敗談を話して学んだこと関西Javaエンジニアの会(関ジャバ) '17 10月度 - connpass https://kanjava.connpass.com/event/68169/ での発表資料です。
マイクロサービスとDDDをGo言語とScala+Akkaで比較したらEventSourcingの話にもなって面白かったまとめ - yoskhdia’s diary
Reactive Messaging Patterns読書会のなかで、「マイクロサービスとAkkaとGo」な面白い話題が出たので代表でまとめる試みエントリです。（結構、色々な話題に飛んでいるので難度高い。） まとめ方としては、会話ログを転記して、最後にまとめる形をとっています。また、議論と私の考えが混ざらないように所感は分けておきます。 ddd-cqrs-es.connpass.com TL;DR 要素技術（どんな言語使うとか、どんなアーキテクチャにするとか）の前に、組織やプロダクトの性格を考えて戦略を決めましょう。 そして、その中で最適と思われる戦術をとれるような要素技術を採用しましょう。 Akka良いよ。 ログ（一部抜粋） Slackからの引用のためテキストベースです。 事の始まりは、荒木さん（以下、 @applideveloper ）の発言でした。 （この記事絡みですね。 集合知で各
bliki: Anemic Domain Model
This is one of those anti-patterns that's been around for quite a long time, yet seems to be having a particular spurt at the moment. I was chatting with Eric Evans on this, and we've both noticed they seem to be getting more popular. As great boosters of a proper Domain Model, this is not a good thing. The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing
70ページでドメイン駆動設計の要点を押さえられるDomain-Driven Design Reference - hitode909の日記
Domain-Driven Design Reference，Amazon見てたら発見して，安かったから買ってみた． ぺらっとしてて，ポケット索引集みたいな雰囲気．エリックエヴァンスのドメイン駆動設計から，要約が抜粋されていて，70ページくらいで，重要な概念を押さえられる．原著は著者の経験を語ってくれるコーナーが大半を占めるけど，この本ではバサッと切られて，定義だけが載ってる． 前の本から10年くらい経ったので，新しい内容も増えてる．ドメインイベントとパートナーシップ，巨大な泥団子．いずれも実践ドメイン駆動設計に出てきた． これだけ読んでドメイン駆動設計さあ始めよう，とはならないだろうけど，でかい本読みたくないけど議論には参加したい，とか，どんなものか軽く眺めたい，みたいな人が読むにはてっとり早いかもしれない． 唯一役立ったのが前書きで，エリックエヴァンスのドメイン駆動設計の本のことをTh
某S社のddd(メイリオ)
2. 自己紹介 名前@kumake1004 ‒ Sansan 株式会社 アプリケーションエンジニア ‒ 2011年入社 (5年目) 仕事 ‒ 法人向け名刺管理アプリのサーバーサイド実装 ‒ アプリエンジニアとインフラエンジニアの板挟みにあうこと 興味 ‒ .NET (C#) / DDD / テスト / マネジメント 3. どうしてこうなった駆動開発とは 職場で DDD 導入したら失敗しました ‒ (個人の感想です) 再挑戦を始めたところ、、、 ‒ 漠然と思いはあって、良い機会なので振り返って言語化します ‒ という普通の失敗事例紹介 つまりただの出オチ 4. - 実践ドメイン駆動設計 コアドメイン (スクラム) における集約の使用 “彼らには DDD の経験があまりなかった。そのため、チームは DDD に関 してちょっとした間違いを犯した。” “最終的に彼らは、自分たちが集約を扱った経験を
RailsでDDD - Qiita
別のアプローチによる実装の記事を書きました。 よろしければこちらもご覧ください。 「かんばん」を、DDDで設計しRailsで実装してみました。 kanban_core_extension 現時点では、最小限の機能しかありませんが ドメイン駆動設計をRailsで実装する際の一例として参考になれば幸いです。 アプリケーションの機能 開発するフィーチャ（タスク）をカードで表現し、進捗状況をかんばんボードで可視化する カードを次のフェーズ（進捗の区切り）に進める時にWIP制限をチェックする アーキテクチャスタイル Event SourcingなしのCQRSです。 変更（Command）の時だけドメインモデルを使います。 問い合わせ（Query）では、必要なデータをデータベースから直接取得します。 リポジトリからドメインモデルを取得することはしません。 取得したデータは構造化されたオブジェクトですが
大型フロントエンド開発におけるTypeScriptとDDD // Speaker Deck
All slide content and descriptions are owned by their creators.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - google/go-github: Go library for accessing the GitHub v3 API
GitHub - Shinpeim/NekogataDrumSequencer