Modeling Forum 2018 技術公演トラックで発表した内容となります。 VernonVaughn Vernon 氏が発表 した書籍「 実践ドメイン駆動設計(通称: IDDD )」の 流れに沿って、 DDD の基本からモデリング手法までを 幅広く紹介します。Read less
![「実践ドメイン駆動設計」 から理解するDDD (2018年11月)](https://cdn-ak-scissors.b.st-hatena.com/image/square/eaa4a1ea772bb0d76ee850149721565aa0c0c40d/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fiddd-201811-181129030409-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
11/18(SAT)にJJUG CCCという、日本のJavaコミュニティの最大規模のカンファレンスで発表してきましたー。1000人を超える申し込みがあるような感じです。そんな場で登壇させていただいて幸せです。 www.java-users.jp 僕のセッションにも 沢山の人が来てくれました。ありがとうございます(∩´∀`)∩ワーイ お話しした内容は この記事のタイトルの通り、僕がDDDを勉強したりDomain Event使ってみたいと思ったりKafkaでCQRSの素振りをしている背景と現状についてです。スライドはこちら。 speakerdeck.com セッションに参加してない方にも喋った雰囲気が伝わるといいなと思って、コメントを加えたりしてみました。スライド内のリンクをクリックしたい方はSpeaker DeckからPDFでダウンロードができるのでそちらをどうぞ。 デモプロジェクト もアッ
前提 私は「エリック・エヴァンスのドメイン駆動設計」を読んだのみで、「実践ドメイン入門」は未読(とても欲しい)の状態で書いています。 (「実践ドメイン入門」にはもっと深い洞察が書いてあるのだと思います…) また「エリック・エヴァンスのドメイン駆動設計」と共に、参考リンク先をまず読んだことがある前提で書いている部分がありますのでご注意下さい。今後もっと良いアイデアが浮かんだり、実際に実装するにあたって浮かび上がった課題があれば随時追記・記事にできればいいなと思います。 参考 CQRS Documents by Greg Young Greg Young流CQRS - Mark Nijhof CQRS+ES DDDから更にData Flowの概念を取り込んだarchitecture。 コマンドクエリ分離原則(CQS/Command Query Separation)に基づく。 CQRSは Co
The CQRS pattern can do wonders: it can maximize scalability, performance, security, and even “beat” the CAP theorem. Nonetheless, CQRS has acquired a controversial name because of the complexity it introduces. For instance, in his article on CQRS, Martin Fowler argues that the pattern should be applied sparingly and even cautiously: “… for most systems CQRS adds risky complexity” “… you should be
Reactive Messaging Patterns読書会のなかで、「マイクロサービスとAkkaとGo」な面白い話題が出たので代表でまとめる試みエントリです。(結構、色々な話題に飛んでいるので難度高い。) まとめ方としては、会話ログを転記して、最後にまとめる形をとっています。また、議論と私の考えが混ざらないように所感は分けておきます。 ddd-cqrs-es.connpass.com TL;DR 要素技術(どんな言語使うとか、どんなアーキテクチャにするとか)の前に、組織やプロダクトの性格を考えて戦略を決めましょう。 そして、その中で最適と思われる戦術をとれるような要素技術を採用しましょう。 Akka良いよ。 ログ(一部抜粋) Slackからの引用のためテキストベースです。 事の始まりは、荒木さん(以下、 @applideveloper )の発言でした。 (この記事絡みですね。 集合知で各
はじめに 弊社で開発するモバイルバックエンドのサーバサイドAPIアプリケーションコード (Play framework + Scala) はビジネスロジックを担う主要なパッケージである services, domains が外部のインフラやAPIインターフェイスに直接依存しないようなパッケージ構成をとっています。(Clean Architecture) services, domains の構成についてはDDDの経験が浅く、まだまだ改善の余地があると考えており、今後どうしていくか考えていくにあたって参考になるであろうページをまとめてみました。 尚、DDDまわりにおける筆者の現在の知識はドメイン駆動設計の第二部までを読み終わり、第三部を読み始めた程度です。 DDDと関連のあるCQRS+ES(Command and Query Responsibility Segregation + Even
autoscale: true Read/Write Stack | JavaScriptアーキテクチャ 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info This is Bikeshed.js :bike: 抽象的な話が多いので、実装はコード見て(Pull Request投げて!) これが正しいという話ではないです。 自転車置き場の議論なので! 中規模以上のJavaScript 設計が必要になる 正しい設計はない Bikeshed.js :bike: 人、目的、何を作るかによってアーキテクチャは異なる 前回の続き? : How to work as a Team 用語 設計の目的 中規模以上のウェブアプリ SPAというよりは、画面が複雑なElectronアプリのようなイメージ スケーラブル 人、機能追加、柔
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
Reactive Messaging Patterns with Actor Modelを読んで見る Vaughn Vernon氏の「実践ドメイン駆動設計」を読んだのですが、C#のソースの紹介しかなくて、いまいちScalaでどのように実装してよいか わからなかったので、同著者の「Reactive Messaging Patterns with Actor Model」(RMP本(仮))を買って読んでいます。 Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka 作者: Vaughn Vernon出版社/メーカー: Addison-Wesley Professional発売日: 2015/07/13メディア: Kindle版この商品を含むブログを見る 実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く