100日間かけてエヴァンス本を完読しました（PDF公開） - そこに仁義はあるのか(仮)
11/25から3/4の100日間かけてエリック・エヴァンスのドメイン駆動設計を完読しました！ ソフトウェア開発の複雑さに立ち向かうための方法に「ドメイン駆動設計」があります。 エリック・エヴァンスのドメイン駆動設計（以降、エヴァンス本）は発売から20年・日本語訳発売から10年経っても読まれていて、ドメイン駆動設計の原著であり、多くのエンジニアが名著という一冊です。 その分厚さや内容が難しそうというイメージからずっと積んだままになっていている人も多いのではないでしょうか。 エリック・エヴァンスのドメイン駆動設計 作者:Eric Evans翔泳社Amazon 私もそんな一人で、ドメイン駆動設計をなんとなく知った風に過ごしていましたが、ドメイン駆動設計に関する勉強会への参加をきっかけにエヴァンス本と向き合い、知ったこと・学んだことを毎日1ページにまとめてツイートする活動を始めました。 100日間
過大評価されるDDD（ドメイン駆動設計）
この記事は、著者の許可を得て配信しています。 Is Domain-driven Design overrated? ドメイン駆動設計（DDD）は、システムのモデリングと構築のための優れたガイドラインを提供する大変便利なアプローチですが、それ自体が目的ではなく、目的のための手段です。その概念は有効ですが、それを使うことだけに限定すると、その一方で多くのことを失うことになります。つまり、実際にはDDDの先にも人生があるということです。 最近、「DDD は過大評価されている」というクリックベイトなタイトルの記事を投稿したところ、皆様からかなり注目を集めました。今回の記事は、社内やソーシャルメディア（TwitterやHacker Newsなど）で受けたフィードバックを取り入れて、前回の記事に内容を加えたものとなっています。また、私の考えにもう少しニュアンスを加えたかったので、あまり過激なものにはし
ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性
![ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/468995f3b9ed8114c64ac798322572db942591ca/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20201221%2F20201221103037.png)
FBZにおけるドメイン駆動設計（DDD）とサーバーレスアーキテクチャを組み合わせた設計戦術 - ZOZO TECH BLOG
はじめに BtoB開発部の木目沢です。Fulfillment by ZOZO（以下FBZ）で提供しているAPIの開発に携わっております。 FBZに関しては以前、物流支援サービスを支えるAWSサーバーレスアーキテクチャ戦略で、AWSサーバーレスアーキテクチャ関連のサービスをどのように活用しているかをご説明しました。 techblog.zozo.com 今回は、サーバーレスアーキテクチャの特徴、設計するうえで課題だった点、そしてそれら課題をどのように克服していったかご紹介します。 イベント駆動と分散処理 FBZではAWSサーバーレスアーキテクチャ関連のサービスを採用しています。その大きな特徴は「イベント駆動」であるという点です。 Lambdaはイベント駆動のサービス 例えば、API GatewayへのリクエストやDynamoDB、S3などへのデータのプッシュイベントをトリガーにLambdaを起
ドメイン駆動設計に関する何か - 日々常々
2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ
現場でDDD 雑感 #genbadeDDD - mike-neckのブログ
現場でDDD という勉強会の第二回があったので参加してきた。 イベント募集のツイートを見たときに既に人数が埋まっていたので、参加できなさそうだなと諦めていたものの、前日に参加できそうなセッションがあったので、参加してきた。当日参加人数を確認したら、申し込み時点で参加できなかったセッションも参加可能になってて、キャンセル多いなと思った。 genbade-ddd.connpass.com genbade-ddd.connpass.com 前半は増田さんの「コアドメインについて語り合ってみよう」というセッションで、いくつかのグループに分かれて、DDD を取り入れている人の事例を元に語るセッションに参加した。 僕が参加したのは某教育サービスのシステムで、どのようなシステムであるかを概観した後、このビジネスのコアドメインは何であるかを議論した。そして実際に開発している方の会社でも認識している、このビ
BirthdayというValueObjectはありなのか？杉本氏（@sugimoto_kei）の考えのまとめ
たなかこういち @Tanaka9230 BirthdayにasLocalDateとcalcAgeというメソッドを生やすか、getDateとgetAgeというメソッドを生やすか、インターフェースなら、後者の方が本来"正しい"のでしょう。 twitter.com/sugimoto_kei/s… 2019-09-06 22:38:14 杉本啓 @sugimoto_kei 「fisrtNameとlastNameはインスタンス変数として保持されているが、fullNameは保持されていない」という知識を隠すのが情報隠蔽であって、前者と後者を区別したら隠蔽にならないじゃないか。 2019-09-06 21:45:06
僕とDDDとClean ArchitectureとやっぱりDDD - kenfdev’s blog
2022/04/21更新 ふりかえってみて、この記事は手段と目的をごっちゃにしちゃった自分がよくわかる記事です。 DDDは「どうやってコードを書くか」が問題ではありません。その点を勘違いしちゃってるエンジニアの話として、続きを読みたい人は読んでください🙏 DDD（Domain Driven Design）って難しいですよね。難しい難しいとばかり考えていた僕もようやく最近になって少しずつわかってきた気がします。そのきっかけとなった書籍と僕のストーリーを本記事で紹介できたらと思います。 TL;DR Clean Architectureはなんとなくわかる DDDは難しい と感じている人は「Domain-Driven Design in PHP」を読むと道が拓けるかもしれない。 leanpub.com 僕とDDD DDDといえばEvansのドメイン駆動設計： エリック・エヴァンスのドメイン駆動設
大失敗した設計、そしてドメイン駆動設計の基本に立ち返る – 福地春喜のブログ
※ 2019年7月27日に追記しました。 この記事の最後に、失敗談の補足を書いた記事へのリンクを追加しました。 システムの一部機能を改修するテーマが現在進行中です。テーマは他の箇所に影響がないくらいに分離できるものです。この大きさが丁度いい。チャンスとばかりにリファクタリングすることにしました。 アプリケーションはそれなりにレイヤー化されています。controllerとserviceとrepositoryがある。よくある３層構造です。何を見直して再設計するのか？それはドメインオブジェクトモデルの構築です。 現状のアプリケーションはビジネスロジックをモデリングしたものとは言えない状態です。自分がやったのだけれど。しかしだからでもあります。なぜこうなったかを振り返り、どのようにできたかを考えます。失敗から学べることもあるはずです。 参照側の層は薄く？本当に？ 開発対象のシステムはある情報の検索
ドメイン駆動設計を理解する３つのキーワード - ソフトウェア設計を考える
ドメイン駆動設計との出会い １０年前に、エヴァンスのドメイン駆動設計を初めて読んだ時は、書いてある内容がほとんど理解できなかった。 あまり、面白いとも思わなかった。 当時は、現場でバグだらけのコードと格闘していた。障害が報告されるたびに、リファクタリング本を参考に、該当個所の長いメソッドや大きなクラスを片端からリファクタリング。その結果、コードがわかりやすくなり、やっかいなバグが単純な修正で解消できてしまうことの効果に驚き、設計の重要性を再認識していた。 それ以前は、UNIXとC言語、OracleとPL/SQLという、オブジェクト指向ではない世界で技術を身に着けてきた。 どちらかというとオブジェクト指向には、ネガティブな印象を持っていた。現場では役に立たんだろうと。 バグとの格闘の中で、リファクタリング（設計改善）の威力を肌で感じ、その考え方とやり方がオブジェクト指向に由来するということを
関Javaで「各レイヤーからのエラーについて考える」を話しました - 毎日Learning
ちょっと時間空いてしまいましたが、登壇した件を備忘録にしておきたいので、書きます。 kanjava.connpass.com こちらで、話してきました。 speakerdeck.com 以下、所感などなど… 登壇の経緯 関Javaでの登壇は、KANJAVA PARTYに続き2回目です。 yoshiyoshifujii.hatenablog.com 登壇のきっかけは、 @tan_go238 さんが、Twitterで公募?されていたので、エントリーさせていただきました。 🙋♂️— Yoshitaka Fujii (@yoshiyoshifujii) 2017年10月6日 登壇内容 ドメイン駆動設計は、現在、自身が関わらせていただいているプロジェクトで採用しており、前のプロジェクトと合わせて、2年半ほどトライしてきております。 その中で、レイヤー化アーキテクチャ、三層+ドメインモデル、オニオ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Dojo 挫折しないドメイン駆動設計 20210825pm
ICONIXプロセスを（途中まで）実践してみた | ともえーぬのブログ
マンガではわからない ソフトウェア開発の真理 | ドクセル
Railsで考えるドメイン駆動設計のコアドメイン
形から入ったドメイン駆動設計によるゲーム開発の光と闇
ピュアなドメインを支える技術/pure domain model and the technology behind it
実践 Clean Architecture
From a legacy monolith to microservices with Domain-driven Design
GitHub - crossroad0201/ddd-on-scala: DDD sample implementation by Scala.
