レガシーをぶっつぶせ。現場でDDD！の資料になります。 https://genbade-ddd.connpass.com/event/127494/
実録！LOHACOにおけるDDDとCleanなArchitecture/DDD and Clean Architecture at LOHACO
レガシーをぶっつぶせ。現場でDDD！の資料になります。 https://genbade-ddd.connpass.com/event/127494/
増田さん/@irofさんのDDDサンプル徹底解説についての雑感 - まっつんの日記
jsug.doorkeeper.jp 本当に面白かった。DB周りの質疑も楽しかった。 内容は他の方のブログ参照。 これとか takeda-san.hatenablog.com 以下雑感 DDDと増田さん流のOOPを使ったアプリケーション開発 個人的にDDDというのは、アプリケーションの目的であるユーザー世界の関心毎を中心に置こう、というだけでコンセプト自体はそんなに特殊なものではなく、ソフトウェアエンジニアリングというか、プログラマー界隈では多くのグルたちが同じようなことを目指していたと思う。要するに関心毎の分離。 いくつかの重要なアイデアが発明されたけど。RepositoryとかAggregateとか、境界づけられたコンテキストとか。 いくつかの点で増田さんのやり方はエバンズが本で書いたものとはずれてたり、ポイントが違っていたりするから、DDDということではなく増田さんというプログラマー
UXD and DDD (UX デザインとドメイン駆動設計) - Qiita
はじめに NewsPicks のソフトウェアエンジニアの三浦です。NewsPicks アカデミア というプロダクトの開発チームリーダーをやっています。NewsPicks Advent Calendar 2018 の12日目を担当します。 今回は、ソフトウェアエンジニア視点でのプロダクトづくりについて、 UX デザイン(以下 UXD)とドメイン駆動設計（以下DDD）を中心に書いてみようと思います。 なぜ UXD と DDD を同時に論じようと思ったのか 結論から先に書くと UXD と DDD は親和性が高いのではないか？と考えたからです。 伝統的なソフトウェア開発のプロセスを挙げると、 要件定義 基本設計 詳細設計 実装 テスト リリース のような構成になると思います。 しかしこのプロセスで開発したソフトウェアはユーザにとって魅力的なものになるでしょうか？ 昔よくあった、やたら入力項目が多か
【Swift】DDDを取り入れたiOS開発 その1 ~UseCaseとdelegate~ | Recruit Tech Blog
この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2015 の投稿記事です。 こんにちは。英語サプリのiOS担当の大島です。英語サプリは10月末にリリースしたばかりのサービスで、アニメーションやBGM・効果音を取り入れたゲーム感覚の英語学習アプリです。iOS版とWeb版がリリース済みでまだサービスは始まったばかりですが、開発期間も短い中でクオリティにこだわってローンチすることが出来ました。当エントリでは、iOSアプリケーションの設計手法について紹介していきたいと思います。 DDD（ドメイン駆動設計）で複雑さと戦う 複雑なiOSアプリケーション開発をしていると以下のような問題点で悩まれているエンジニアの方も多いのではないでしょうか。 すぐにFatになってしまうUIViewController 複数のフラグで状態を管理するUIViewContro
テスト駆動開発における進化的設計とデザインパターンの勘所とは？〜テスト駆動開発をやめて、なお残すべき習慣とは(9)
前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 忘れないで、テスト駆動開発にもデザインパターンの話が出てくるよTDDはテストファーストやベイビーステップのインパクトがありすぎて、あまり目立っていないですが、書籍『テスト駆動開発』にもソフトウェアパターンの話が出てきます。そう、出てくるんですよ。 余談ですが、テスト駆動開発３部におけるSingletonパターンの説明はGoFの説明とは違ったユニークな内容になっています。（本で確認してみてね） 1回だけ設計ではなく繰り返し設計注意点ですが、テスト駆動開発においてのソフトウェアパターンは、プロジェクト初期に１回だけパターンを使って
radarphpでDDDやってみて得た知見 - Qiita
phpでDDDをやってみたのでそこで得た知見を共有します。 ストーリーみたいなものはなくて、「こんな技術面の課題が出てきて、それにこう対応したよ」というTIPSをつらつらと書き連ねていきます。 前書き phpのウェブフレームワークでradarphpというのがあります。 このフレームワークがDDD前提で作られていて、なかなか感じが良かったので見つけてすぐに触ってみたくなりました。 かねてからDDDに入門したいと思っていたこともあって、ちょうどその時HTTPサーバのスタブが必要だったので、試しにDDD + radarphpで作ってみることにしました。 これは趣味のプロジェクトだったのですが、作ってるうちにアプリを作ることよりも良いプログラムを書くことの方に興味が移ってしまって、最終的にプロジェクトの目標も「レイヤーやクラスを納得いくまできれいに整理すること」「グルーコード・ボイラープレート的コ
日本語のドメイン駆動設計 (Domain-Driven Design - DDD) 関連記事まとめ - なにか作る
ドメイン駆動設計は原典となる「エリック・エヴァンスのドメイン駆動設計」の初版が2003年と歴史があり、モダンなフレームワークであればその思想を取り入れた設計がなされているにも関わらず、日本語の情報が少ない気がする。 最近ドメイン駆動設計をやろうと主にWeb上の情報を探っていたので参考になったサイトをリンク集の形でまとめてみる。 概要 概要を把握するのが一番難しいように思うので、色々と目を通すのがよさそう。 little-hands.hatenablog.com enterprisegeeks.hatenablog.com enterprisegeeks.hatenablog.com speakerdeck.com ドメイン駆動設計とは何か 【入門編】 from 増田 亨 www.slideshare.net 3週連続DDDその1 ドメイン駆動設計の基本を理解する from 増田 亨 www
なぜDDD初心者はググり出してすぐに心がくじけてしまうのか - Qiita
DDD連載記事 * なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか * ドメイン駆動設計の定義についてEric Evansはなんと言っているのか * モデルでドメイン知識を表現するとは何か * ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か * ドメイン駆動 + オニオンアーキテクチャ概略 背景 直近のプロジェクトでDDDの思想に則ったアーキテクチャで一つリリースまで漕ぎ付けまして、そこに至るまで色々と調べたり試行錯誤をしながら学んだことを書いていこうと思います。 一番にですね、大体のDDDに興味を持った人がいうのが ということなんですよね。 DDDは思想としてすごく面白く、とても実用性なものなのに、なんでこんなにわかりづらいのか、ハードルが高いのか！！ という点について、私なりの解釈を述べたいと思います。 心をくじく要因 Eric Evans本は説明
ちょっとずつ読むドメイン駆動設計 第ニ部 モデル駆動設計の構成要素 第四章 ドメインを隔離する6 - Qiita
前々回と前回でレイヤアーキテクチャ・DIを使う・ ヘキサゴナルアーキテクチャについて読み進めました。 他の選択肢について 他の選択肢 オニオンアーキテクチャ Jeffrey Palermoが2008年に提唱したアーキテクチャです。 ヘキソゴナルアーキテクチャと似てますね。 特徴は 依存関係は外側が内側に依存します。(もちろんそうするためにDIが必要となります) 外側は内側であればどの層に依存してもいいです。すぐ内側のみということではないです。 ドメインサービスという層というのは、JefferyのブログによるとDDDで言うところのRepository(インターフェイス)を集めた層のようです。 実装の仕方は内側にインターフェイス、外側にそのインターフェイスを実装します。 アプリケーションCoreは様々と言っているので、必ずしもこの通りにしなければならないわけではないようですが、必ずドメインとそ
[DDD]ドメイン駆動設計の定義についてEric Evansはなんと言っているのか - Qiita
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 ドメイン駆動設計について、「どうやって実装するのさ？」の前に、まずは定義について認識合わせをしたいと思います。 背景 「ドメイン駆動設計とは何か？」 ドメイン駆動設計について興味を持った時に、一番最初に疑問に思うのがこれですね。 ところが、ググって見ると結構いろんなサイトでいろいろな書きぶりをしているんですよね・・・。 「顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法」 ドメイン駆動設計のメリットと始め方(Codezine記事) 「厳しい現実の中で、
![[DDD]ドメイン駆動設計の定義についてEric Evansはなんと言っているのか - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/b2e6bf6f219b0a6d8c0c7049b4085113f956abe4/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-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCREREJTVEJUUzJTgzJTg5JUUzJTgzJUExJUUzJTgyJUE0JUUzJTgzJUIzJUU5JUE3JTg2JUU1JThCJTk1JUU4JUE4JUFEJUU4JUE4JTg4JUUzJTgxJUFFJUU1JUFFJTlBJUU3JUJFJUE5JUUzJTgxJUFCJUUzJTgxJUE0JUUzJTgxJTg0JUUzJTgxJUE2RXJpYyUyMEV2YW5zJUUzJTgxJUFGJUUzJTgxJUFBJUUzJTgyJTkzJUUzJTgxJUE4JUU4JUE4JTgwJUUzJTgxJUEzJUUzJTgxJUE2JUUzJTgxJTg0JUUzJTgyJThCJUUzJTgxJUFFJUUzJTgxJThCJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1lYzNhNzlmYWI4YmFiZWI5ODU2YjgyNDY3YjJkZTVhNw%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbGl0dGxlX2hhbmRfcyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9M2M3NjhmN2VjOTAyM2RiNTMyMGEzMjE4ZDU3NGE0NjY%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D386aabccbd8fd5fc3ab7c6f8c5ba410f)
PHPでDDD実装事例(クラス図、コードレビューでの指摘ポイント有り) - Qiita
追記 1.一意な識別子を生成するnextIdentity()メソッドの実装を追記しました 2.ReservationServiceクラスを修正しました (リファクタリング、Customerクラス追加) 3.続編では無いですが、その②を書きました。 PHPでDDD実装事例その②リポジトリ&ファクトリで永続化・生成処理をカプセル化(Laravel)(図あり) 背景 自分が運営しているハウススタジオの予約受付業務の自動化システムを、今学習しているDDD風に設計して、YYPHPにてコードレビューしてもらったので、 ・前提となる業務の内容 ・業務ルール ・クラス構成(クラス図) ・設計の考え方 ・実装コード ・レビューでの指摘ポイント あたりを共有しようと思います。 未熟な部分もあると思います。 この記事を読んで改善点などあれば是非是非コメント下さい！ 言語はPHP、フレームワークはLaravelで
#jjug_ccc 僕がDDDを勉強したりDomain Event使ってみたいと思ったりKafkaでCQRSの素振りをしている背景と現状 - Mitsuyuki.Shiiba
11/18(SAT)にJJUG CCCという、日本のJavaコミュニティの最大規模のカンファレンスで発表してきましたー。1000人を超える申し込みがあるような感じです。そんな場で登壇させていただいて幸せです。 www.java-users.jp 僕のセッションにも 沢山の人が来てくれました。ありがとうございます(∩´∀｀)∩ﾜｰｲ お話しした内容は この記事のタイトルの通り、僕がDDDを勉強したりDomain Event使ってみたいと思ったりKafkaでCQRSの素振りをしている背景と現状についてです。スライドはこちら。 speakerdeck.com セッションに参加してない方にも喋った雰囲気が伝わるといいなと思って、コメントを加えたりしてみました。スライド内のリンクをクリックしたい方はSpeaker DeckからPDFでダウンロードができるのでそちらをどうぞ。 デモプロジェクト もアッ
はじめてドメイン駆動設計をしてみて感じたこと - Qiita
この記事はCrowdWorks Advent Calendar 2017の4日目の記事です。 はじめに 今年CrowdWorksにエンジニアとして新卒入社した@kinakoboです。CrowdWorksでは10月から新たな試みとしてドメイン駆動設計（DDD）を実践しています。 DDDを実践するに至った経緯は、サービスの規模拡大に伴いアプリが肥大化し、技術的負債が増えてきたことで、機能追加をスピーディーに進めづらくなってきたからです。 今回実装しようとしている機能を今まで通りRuby on Railsを利用して実装することは可能ですが、変更に強い柔軟なサービスにするためにもDDD+Scalaで実装し始めています。 DDD未経験の状態から2ヶ月実践してみて、まだ道半ばですが感じたことを書きます。同じような課題感を持っている方の参考になれば幸いです。 エヴァンス本に挫折したら･･･ DDDと言え
goddd とは何か? - pospomeのプログラミング日記
これは Go Advent Calendar 2017 その2 6日目の記事です。 https://qiita.com/advent-calendar/2017/go2 みなさん、こんにちは。 pospome です。 普段は GAE/Go でサーバサイドの開発をしています。 twitter では 実装パターン, DDD, golang, GCP についてつぶやくことが多いので、 同じような分野に興味があれば、 フォローしてマサカリ投げてもらえると嬉しいです。 https://twitter.com/pospome ということで本題に入ります。 golang.tokyo #9 で goddd という github リポジトリを知りました。 https://golangtokyo.connpass.com/event/65921/ ちょっと興味があったので、 goddd に対する自分の感想を書
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - masuda220/business-logic-patterns: experiments for business logic patterns
DDDリポジトリを楽に実装するライブラリ - Qiita
Eric Evans氏はDDDが完璧主義者のためのものではないと述べた
(旧版)DDD × CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD失敗談を話して学んだこと
