ドメイン駆動設計をわかりやすく - ドメインのモデル設計を手を動かしながら学ぼう｜ハイクラス転職・求人情報サイト AMBI（アンビ）
ドメイン駆動設計をわかりやすく - ドメインのモデル設計を手を動かしながら学ぼう ドメイン駆動設計（DDD）が近年関心を集めていますが、同時にこの設計思想は難しい、わかりにくい、という見方もあります。さまざまなプロジェクトでドメイン駆動設計を実践してきたかとじゅんさんが、サンプル課題をもとに、ユースケース分析、モデル設計といった基礎を解説します。 はじめまして、Chatworkでテックリードをしている、かとじゅん（ @j5ik2o ）です。 僕は2010年ころより、大小さまざまなプロジェクトでドメイン駆動設計、いわゆるDDD（Domain Driven Design）を導入した開発を実践してきました。ドメイン駆動設計を主題としたワークショップなども主宰していますが、最近では加速度的にこの設計思想への関心が高まっていると感じます。本稿では、なにかと分かりにくいドメイン駆動設計の基本を、架空の
ドメイン駆動Vuexで複雑さに立ち向かう
スタディスト開発部、フロントエンド担当の小宮山です。走ることが楽しくなりすぎてフルマラソン完走が当面の目標です。 今回は私達が進めているUIリニューアルプロジェクトにおける、フロントエンド設計の心臓部についてご紹介したいと思います。盛り上がりつつあるものの、まだまだ実践的な情報が少ないVue界隈に少しでも貢献できましたら幸いです。 画面駆動Vuexの頃プロジェクト始動当時は私含め大規模プロダクトにVuex（さらにその他Flux状態管理も）を導入して開発を進める経験も知見もほぼない状況でした。 そして開発していく画面デザインの大枠は出揃っている状態だったので、計画も実装も画面単位で区切って進みだしていきます。 こうした状況でVuexのstoreはどのような方針で実装されていくか。正確に表現するなら、特に方針なく実装していくとどうなるか。画面ファーストで、画面から使いやすく、画面ごとに専用なs
makopi23のブログ 「JSUG勉強会 2019その2 Spring BootベースのDDDサンプル徹底解説！」に参加しました
2019/2/18(月) 「JSUG勉強会 2019その2 Spring BootベースのDDDサンプル徹底解説！」に参加してきました。 Doorkeeper https://jsug.doorkeeper.jp/events/86655 Togetter https://togetter.com/li/1320727 参加の経緯 これまで「エリック・エヴァンスのドメイン駆動設計」や「実践ドメイン駆動設計」の読書会に参加したりして一通り書籍は読んでいるものの、コードのイメージが中々掴めないままでモヤモヤしてたので、このイベントはホントありがたい～ 事前にGitHubのリポジトリからDDDサンプルをcloneしてEclipseにインポートし、手元でアプリを動かしてみたり、コードをいくつか眺めてみたりして、勉強会中にもすぐ見て触れる状態にしてから参加しました。 聴講メモ はじめにDDDサンプル
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
2017年7月5日紙版発売 2017年7月5日電子版発売 増田亨 著 A5判／320ページ 定価3,234円（本体2,940円＋税10%） ISBN 978-4-7741-9087-7 Gihyo Direct Amazon 楽天ブックス honto ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 「ソースがごちゃごちゃしていて，どこに何が書いてあるのか理解するまでがたいへん」「1つの修正のために，あっちもこっちも書きなおす必要がある」「ちょっとした変更のはずが，本来はありえない場所にまで影響して，大幅なやり直しになってしまった」といったトラブルが起こるのは，ソフトウェアの設計に問題があるから。日本最大級となる60万件以上の求人情
Scala界隈でDDDが大いに盛り上がったのでログをまとめましたよ-その1 - Kuchitama Tech Note
以前、ScalaJpのgitter.imでDDDについて議論が盛んに行われてたけど、いずれログが消えちゃうのがもったいなくて、ここに内容を貼付けます。 scalajp/public - Gitter 要約すると実践DDD本出たらみんなで読もうぜ。ってことで。 実践ドメイン駆動設計 (Object Oriented Selection) 作者: ヴァーン・ヴァーノン,高木正弘出版社/メーカー: 翔泳社発売日: 2015/03/17メディア: 大型本この商品を含むブログ (1件) を見る ホントは、自分のブログとかじゃなくてGistとかがいいんだろうけど、見た目を整えるのが一番楽なので、ここに掲載しておきます。 一応、最初にまとめるにいたった経緯↓ xuwei-k 2015年2月24日 gitter、無料だとログの保存期間2週間って話だったけど、実は現状全部残ってる https://gitte
ドメイン駆動設計のリファレンス本 | 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
技術/ソフトウェア設計/ドメインモデル(Domain Model), Service Layer周辺 - Glamenv-Septzen.net
id: 1286 所有者: msakamoto-sf 作成日: 2014-05-06 23:06:40 カテゴリ: Java システム開発 プログラミング [ Prev ] [ Next ] [ 技術 ] 会社で、Ruby on RailsのバックグラウンドがあるけどJavaはそれほど深くない人向けに、Javaでのオブジェクト指向設計とか、パッケージやクラスの分け方、置き方を説明した方が良いかなーという場面が出てきました。 が、いざ棚卸ししてみますと、特にドメインモデル周辺について自分も良く理解してない点が多々有りまして。なんかざっと記事を漁ってみまして、それのログというかメモ書きになります。 全体的に「如是我聞」な内容・・・どころか、そのまんま載せるのに力不足でもしかしたら曲解・誤解して書いてる内容があるかもしれません。とにかく参考資料（記事のURLや、PoEAA本のP数）については載せ
Functional Patterns in Domain Modeling - The Specification Pattern
When you model a domain, you model its entities and behaviors. As Eric Evans mentions in his book Domain Driven Design, the focus is on the domain itself. The model that you design and implement must speak the ubiquitous language so that the essence of the domain is not lost in the myriads of incidental complexities that your implementation enforces. While being expressive the model needs to be ex
ドメイン駆動設計と相互依存性
こっつん @cttsn @j5ik2o https://t.co/CM8DigG9qZ かなり参考にしてます！ 例えばユーザは複数グループに所属でき、ユーザの所属一覧とグループのユーザ一覧と両方欲しい場合、所属エンティティの属性にユーザとグループ内の値オブジェクトをコピーすればいい感じですかね… 加藤潤一(かとじゅん) @j5ik2o @pnkts あ、だいたいわかります。ユーザはグループではないのでグループを表す属性は持ちませんし、その反対も同様です。なので、ユーザには所属する複数のグループへの参照を持つか、グループが所属される複数のユーザへの参照を保持するかという話になりますね、たぶん(続く 加藤潤一(かとじゅん) @j5ik2o @pnkts まず相互依存の関連は維持管理がシビアなので最初から前提にしないで一方向になるようにしましょう。つまり便利な関連は排除し本質的な関連だけにする。
オブジェクト指向設計の４つの流派からドメイン駆動設計へ - プログラマの思索
先日の大阪DDD勉強会に刺激を受けて、「ユースケース駆動開発実践ガイド」と「オブジェクト開発の神髄」と「アジャイルソフトウェア開発の奥義」「実践UML」を読み直している。 ラフなメモ書き。 【元ネタ】 【限定募集：第1回の申込者のみ、参加登録可能】第２回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper vol2_20140309 · dddosaka/reading_ddd_report Wiki 【１】個人的には、オブジェクト指向設計という考え方は好き。 データモデリングはDB設計でも業務の設計でも必須だが、データだけではシステムは動かない。プログラムも作る必要があるけれど、DOAにこだわると、なぜかソースの自動生成に走ってしまうように思える。 オブジェクト指向設計は、アジャイル開発と相性がよい。 また、開発チームの構造解析にもオブジェクト指向設計
ドメイン駆動設計読んだ - hitode909の日記
ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で，Kindleで買えたので読んだ．ドメインを軸に戦略的に設計しましょうという本．2週間くらいで読めて良い体験できてよかった． ソフトウェアを，ユーザーインタフェース，アプリケーション，ドメイン，インフラストラクチャという4つの層に分けて，一番重要なのがドメイン層で，ドメイン層にアプリケーションが存在し得る理由がある．銀行システムだったら，口座とか利子みたなやつがドメイン層で，口座がよくできてると銀行としてうまくいく．ATMのタッチパネルというのはユーザーインタフェースで，どんなにATM押しやすくても，ドメイン層に，口座という概念がなくて，ただのハッシュだったりすると，銀行を運営して金を儲けるとか，新たな金融商品とか作るのが困難になる．インフラ層は永続化とかするのだけど，インフラ層がいかによくても，意味ないデータを保存していては銀行倒
ServiceとDCIについて - じゅんいち☆かとうの技術日誌
面白そうなネタがあったので、自分なりの考えをまとめてみる。 Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて この記事はRuby用のDIコンテナの話題なんですが、DCIについても言及されているようです。比較軸はDIそのものというより、サービスとDCIだと思うので、それについてダラダラといくつか考えをまとめてみます。多分も返事になるようでならないかも。それと宗教上の都合でDDDの視点から書きます…。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に”サービス”って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用するためのものです。後者はドメインの知識
ドメインを巡るお話 | Uzzu::Blog
Jan 4 2014Tags: dci ddd 昨年末にだらだらDCIに関する自分の考えを整理したくて身内で話していて、 結論としては「DDDとDCIどちらもメンタルモデルに近づけるために機能してる点は変わらない。その先DDDあるいはDCIをフレームワークにするか、あるいは一部に取り入れるのか、そこは取組むドメインによって取捨選択だよね」というところに落ち着いたのだけれど、勿体無い内容な気がするので改めてブログに書くことにする。 DDD脳から見たDCIの考察 DCIはFATなドメインモデルに対するアプローチというよりは、シナリオを明確にするためのアプローチなのかなと思う。 DDDを実践するような複雑な問題に直面した時、ドメインモデルは山のように増える。より知識を噛み砕いてドメインモデルにしたほうがより上層のロジックが簡潔になるので積極的にドメインモデルに落とし込む方がよく、結果として、シナ
ドメイン駆動設計・アプリケーション構築編・モジュール - Strategic Choice
MODULESグルーピングのモデリング別名パッケージ（PACKAGES）俯瞰図所属するストーリの俯瞰図です。アプリケーション構築どういうこと？モデルもコードも意味のある単位に分割し、モジュールとしてまとめます。プログラミングの場合と同じく、モデルのモジュール分割においても高凝集・低結合が重要な目安になります。関連し合う概念同士はひとつにまとめ（高凝集）、かつ一度に考えなければいけない範囲は最小限にします（低結合）。どうして？モデルも分割統治モジュールに分割されるのはコードだけではありません。概念も分割されます。モジュール内では高凝集、モジュール間では低結合が必要です。人が一度に考えられる物事の数には限りがありますし（ゆえに低結合)、首尾一貫していない思考の断片は理解するのが難くなります（ゆえに高凝集)。モジュールもモデルモジュールも、モデルの一部です。モデルを表現し、深化させなければなりま
Scalaコードでわかった気になるDDD | GREE Engineering
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
SNSチームでのドメイン駆動設計の実践 | GREE Engineering
こんにちは！グリープラットフォームでSNSの開発をしています、うきょーです！ GREE Advent Calendar 2013 6日目です、よろしくお願いします！ 今回は僕が所属するチームでの、ドメイン駆動設計を実践してきた過程をお話したいと思います。ドメイン駆動設計とは何か、については簡単に要所要所で説明していきますが、詳しくは本で！また、ドメイン駆動設計そのものについての話ではなく、実践の一例となります。 スマートUIパターンからのスタート 今回僕のチームが扱っていたものはJavaScript製のクライアントアプリケーションで、APIから取得した情報を表示し、ユーザーの操作によってAPIを呼び出す、というごく一般的なものです。 ドメイン駆動設計にはアンチパターンとして、スマートUIパターンと呼ばれるものが存在します。簡単に言えば「見た目都合から設計やモデルを考えてしまった」という状況
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン駆動設計における関数型パターン
DDDがよく分かんないときに見てそこそこ分かった資料置き場 - DRYな備忘録
20110409_DevLOVE「Building Blocks」_都元ダイスケさん
ドメイン駆動設計入門
