EventStormingをやってみた話 - Qiita
はじめに この記事について DDD-Community-jp 内で行っているモデリング会で、EventStormingをやってみた体験談です。 やってみて、いいと思ったこと、ぶつかったこと/悩んだことの紹介になります。 「正しいやり方の紹介」ではない点はご注意ください。 （この段階でこう考えたがあとで修正、などは書くようにしてます) やってみての EventStorming の感想 記事が長くなるので、最初に感想を。 以下の点で、とても強力なツールと感じました。 プロセスが視覚化され、チーム内で意見がぶれるところを発見し、意識統一していける。 集約が簡単に導き出せる。 一方で、以下の点は EventStormingの外で頑張らないといけないと感じました。 要件を出すものではない。別で要件分析が必要そう。 コード化する際、CQRS+ESが前提になりそう。 EventStorming を実施し
新しいモデリング手法: EventStormingをはじめるための準備 - yoskhdia’s diary
EventStorming (イベントストーミング) というモデリング手法があります。 www.eventstorming.com EventStorming is a flexible workshop format for collaborative exploration of complex business domains. EventStormingは、複雑なビジネスドメインを協同的に探求するための柔軟なワークショップ形式のひとつです。（意訳） 考案者はAlberto Brandolini氏で2013年にはブログに最初の投稿がされています。 海外での認知度は高く*1、Eric Evans氏のプレゼンテーションの中でも強力な手法であると言及*2されています。 近々、この手法を試せる機会が来そうなので、そのやり方について（私見を交えつつ）まとめてみるエントリです。 注意 現在進行系
そのプロダクトにポリシーはありますか？（イベントストーミング実施編） - Qiita
GLOBIS Advent Calendar 2021 13日目の記事です。 昨日のエントリでは @tatsushitoji が、イベントストーミングという手法をチームに提案・導入した背景やその効果について書いてくれました。 続編として、今回は「具体的にどうやってイベントストーミングを実践したのか」についてご紹介したいと思います。 ようこそ、イベントストーミング実践編へ！ 僕たちがイベントストーミングを始めるにあたって、もっとも困ったことは実際のケース紹介が少ないことでした。 今回は具体的なテーマに則して、僕たちなりの改良を交えた進め方をご紹介したいと思います。 テーマとしては、Qiitaのアドベントカレンダー投稿機能を考えてみます1。 （アドベントブログの登録画面があり、リンクを登録しておけば当日に自動公開される・・という機能を想定しています） イベントストーミングプログラムの具体的な立
これならできる！ドメイン駆動設計に役立つイベントストーミング - Qiita
はじめに コンテナ技術の進展に伴って、ビジネス環境の変化に迅速に対応できるマイクロサービスに関心が集まっています。最近では、マイクロサービスを分割する方法の一つとしてドメイン駆動設計が注目されています。ドメイン駆動設計では、業務に精通した方々や技術者が、モデリングなどいろいろな技法や専門用語を使い、それらを理解した上で設計を進めていきます。様々なステークホルダーとチームを組んで一緒に取り組むにしても、直観的にはとてもわかりづらいと感じています。そこで、いろいろと記事を調べてみたり、身近な技術者と意見交換をしたところ、イベントストーミングという手法がありました。イベントストーミングに関する記事は他の記事に比べあまり多くはないので、この場で共有しておきたいと思い掲載することにしました。これからドメイン駆動設計をはじめるという方や、既に取り組んでいるけれど進め方に悩んでいる方など、参考になれば幸
ドメイン駆動設計入門【DDDをわかりやすく解説】 | 楽水
突然ですが、エンジニアの皆さま、Javaで開発したWebアプリケーションの構成、このようになっていませんか？ データとgetter/setterだけのオブジェクト（JavaBean） 画面のコントロールやビジネスロジックの処理はServletが行う データベースのアクセスは、DAO（Data Access Object）に任せる もしそうであれば、そのシステム、ドメインモデル貧血症に陥ってます。 これは、データとgetter/setterだけのオブジェクトを、Anemic（貧血症になって元気がない）オブジェクトと称し、オブジェクトとはいうものの実質的にはデータであり、それをやりとりするだけの手続き型システムなっていることを嘆いたものです。 今回は、本来のオブジェクト指向に立ち返り、そのメリットである高い保守性、再利用性、拡張性を備えた変化に強いシステムを作るための設計方法、ドメイン駆動設計
Domain Driven Design Quicklyをさ〜らに要約してみた
はじめに DDDの要約と基本思想の紹介を、短く素早く読めるかたちで公表されているDomain Driven Design（ドメイン駆動設計） QuicklyがInfoQで無料公開されています。 ただこの資料、量が多く読むのがしんどい為、 今回はこれをさらに要約してみました。 参考元 : Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 ドメイン駆動設計とは何か ソフトウェアを開発する目的 ・ 実世界の作業を自動化するためです。 ・ ビジネス上の問題を解決するためです。 ソフトウェアを作るためには 例えば、銀行業務システムを構築するとなった場合、銀行業務について最も大切なことを理解していなければ、銀行業務システムの構築はできません。 つまり、銀行業務のドメインを知る必要があります。 ドメインを知るのは誰？ ✖️ ソフトウエアアーキテクト ✖️ ソフトウェ
[DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほ
![[DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/5f74c5c72ebd18816032917216eeec82801e95ef/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCREREJTVEJUUzJTgzJTg5JUUzJTgzJUExJUUzJTgyJUE0JUUzJTgzJUIzJUU5JUE3JTg2JUU1JThCJTk1JTIwJTJCJTIwJUUzJTgyJUFBJUUzJTgzJThCJUUzJTgyJUFBJUUzJTgzJUIzJUUzJTgyJUEyJUUzJTgzJUJDJUUzJTgyJUFEJUUzJTgzJTg2JUUzJTgyJUFGJUUzJTgzJTgxJUUzJTgzJUEzJUU2JUE2JTgyJUU3JTk1JUE1JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz05MGViZDg5M2ZkOGVlMDZkMGEyOWVkZWMyN2MxMmFkNg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBsaXR0bGVfaGFuZF9zJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02YmZmYzI2ZTBkMjNhZjllYjRjZTJiYTQwODIzMjhhNA%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Da55a404321a639c6fc4f1c3992cbb2b3)
ボトムアップドメイン駆動設計
はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は
DDD with RDRA, ICONIX
DDDを具体的なプロセスに落とし込むにはどういう観点が必要だろうか。 - 境界づけられたコンテキストがどこまでの範囲かよくわからない - ユビキタス言語やドメインモデルをどのように発見すればいいかわからない。どこから着手すればいいのか？ - ドメインモデルがただのデータの入れ物になってしまう(貧血…
「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」について考える
昨今のシステムは、社内外のシステムと連携していて境界定義が難しいといわれています。だから、大きなシステムは人間が制御できるぐらいのサービスに分割する。それがマイクロサービスの考え方の一つです。こういったシステムを分割して構造化する手法は古くから「モジュール化」という手法が有名です。マイクロサービスは現代のモジュールだと考えています。そして、このモジュールは技術的観点よりビジネス的観点で分割したほうがよいといわれるようになりました。具体的にはドメイン駆動設計の「ドメイン」です。これらの「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」はシステム設計を語るうえで重要なキーワードです。今回は、モジュール化とドメインの関係性について考察したいと思います。
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab
DDD連載記事 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっつきやすい」と考えるアーキテクチャを紹介します。 前提としてですが、完全に個人的な経験に基づく私見になります。 DDDの理論の中で、アーキテクチャに関しては「エリック・エヴァンスのドメイン駆動開発」(以下原典)と実践ドメイン駆動開発(以下IDDD)とでも異なったものが紹介されており、唯一の正解
![ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed125204d89ae253a4ab2a6c711eff21748ee9c7/height=288;version=1;width=512/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F30489%2F81fcfd95-2ce1-82a8-db69-8618338a5f22.png)
アプリの状態管理を安全に行うためのFluxとRedux
Fluxの最大の特徴である単方向データフローは、ここにUIである「View」を加えて、図1の通り表されます。 図1 Fluxの単方向データフロー 状態の更新指示内容である「Action」を関数である「Dispatcher」で「Store」に伝えて状態を更新し、その結果を「View（React）」に伝える、といった流れです。 実際にアプリケーションに組み込んだ場合には、ユーザーが画面を操作したイベントに応じて新たなActionを発行（dispatch）して、状態と画面を更新していく形になるので、次の通りになります。 図2 ユーザー操作を考慮したデータフロー 図2に沿って初期化後の処理を一つひとつ見ていくと、次のことをしています。 ユーザーがViewを操作する（ボタンを押す、文字を入力する、など） 更新したい事柄をActionの形にまとめて、Dispatcherに渡す Dispatcherから
実践DDD本 第8章「ドメインイベント」～出来事を記録して活用～
実践DDD本 第7章「ドメインサービス」～複数の物を扱うビジネスルール～ ドメインイベントとは 「ドメインイベント」は、ドメインで起こった出来事をモデリングする仕組みです。ドメインイベントを使うことで、複雑になりがちな出来事を管理し、システム間の連携を柔軟にすることができます。 DDD本の発売後に発展してきた概念のため正式な定義は書かれていませんが、エヴァンス氏は ドメインイベントは、ドメインモデルの一部であり、ドメイン内で発生する何かの出来事を表す。 と述べており、出来事をモデリングする有用な手法と認識していることがわかります。 ドメインイベントのモデリング方法 「エンティティ」や「値オブジェクト」ではオブジェクトの属性や振る舞いに対してモデリングを行ってきました。これに対して、ドメインイベントは「ドメインエキスパートが注目する出来事」にフォーカスします。具体的にはドメインエキスパートが
ドメイン駆動設計、どこまでやるべき？ 開発現場の“問題”を乗り越えるためにできること
ドメイン駆動設計、どこまでやるべき？ 開発現場の“問題”を乗り越えるためにできること ゲーム開発におけるドメイン駆動設計とサーバレスアーキテクチャ #1/2 2019年2月7日、『神姫PROJECT』などソーシャルゲームの企画・開発を手がける株式会社テクロスが主催するイベント「TECH x GAME COLLEGE」が開催されました。渋谷発エンジニア勉強会「ヒカ☆ラボ」とコラボレーションした今回のテーマは「ゲーム開発におけるドメイン駆動設計とサーバレスアーキテクチャ」。過去にTECH x GAME COLLEGEにて講演を行ったギルドワークス株式会社取締役の増田亨氏と、Game Server Services株式会社代表取締役社長CEOの丹羽一智氏をゲストに招き、参加者から事前に募った質問に解答していただきました。前半の本パートでは、ドメイン駆動設計（DDD）やFaaSの未来、チームビルデ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - system-sekkei/library: 図書館の司書業務を支援するソフトウェア
ドメイン駆動設計の正しい歩き方
実践DDD本 第8章「ドメインイベント」～出来事を記録して活用～