複雑な条件の組み合わせで - テストが難しく - 実装が肥大化し - 変更が辛い 状態になったコードを改善する。 Specification Pattern/仕様パターン について、「実装的に嬉しいこと」にフォーカスして整理。
複雑な条件と戦う
複雑な条件の組み合わせで - テストが難しく - 実装が肥大化し - 変更が辛い 状態になったコードを改善する。 Specification Pattern/仕様パターン について、「実装的に嬉しいこと」にフォーカスして整理。
DDD学習指導要項 [Draft 2]
DDD Talk MeetUp #2 LT資料 https://ddd-community-jp.connpass.com/event/141712/
![DDD学習指導要項 [Draft 2]](https://cdn-ak-scissors.b.st-hatena.com/image/square/b2ba52041da09d5d5cab19237718f65adcf05bca/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fef5a77e52e3d4d698db48d165c5a1843%2Fslide_0.jpg%3F13509094)
01_602_Djangoで実践ドメイン駆動設計による実装(大島和輝)
01_602_Djangoで実践ドメイン駆動設計による実装(大島和輝)
僕と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のドメイン駆動設計： エリック・エヴァンスのドメイン駆動設
抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート 大阪
2. 2012 04 新卒入社 ど素人 １年くらい多重度をフランス語だと思ってた（→タジュード） 社会人歴の半分くらいは php でフロントエンド、 後半の半分くらいは Java / DDD をやっている ここ１年ちょっとはテックリードみたいなことも ScalaMatsuri 毎年行ってます、 Haskell Day も行ってみた よ 最近認定スクラムマスターになりました 最近はテスト系の勉強会とかに乱入したりもしています 自己紹介 3. 設計ぽいやつ 1. DDDをHaskellで考える 業務ロジックとシステムロジック 2. 副作用ってなんだ？ 〜楽に小さく単体テストをしよう〜 チーム開発ぽいやつ 3. アジャイル / スクラム / チーム開発の［不吉な匂い］まとめ 4. GitHubを中心とした開発プロセス 予想に反していいねもらえたやつ 5. Pythonのimportについてまとめ
世界一わかりやすいClean Architecture - nuits.jp blog
本項は「C# Tokyo オンライン「世界一わかりやすいClean Architecture」他」による発表の登壇原稿となります。過去に発表した.NET版の記事はこちらにアーカイブしています。 本稿のサンプルコード・PPTはこちらで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 github.com また動画を以下で配信しています。よろしければご覧ください。 世界一わかりやすいClean Architecture はじめに まず初めに、クリーンアーキテクチャの誤解されがちな二つのことについてお話させていただきます。 その上で、クリーンアーキテクチャの本質とは何か？押さえておくべき、本当に重要だと考えている三つの事について、お話しします。 注意事項 さて本題に入る前に、少し注意
DDDとRDRAを組み合わせて使うには
RDRA1.0とDDDを組み合わせた経験から以下の観点 について解説 1) いきなりドメインモデルを考えられるか 2) ドメインモデルの周辺環境を探索する
大失敗した設計、そしてドメイン駆動設計の基本に立ち返る – 福地春喜のブログ
※ 2019年7月27日に追記しました。 この記事の最後に、失敗談の補足を書いた記事へのリンクを追加しました。 システムの一部機能を改修するテーマが現在進行中です。テーマは他の箇所に影響がないくらいに分離できるものです。この大きさが丁度いい。チャンスとばかりにリファクタリングすることにしました。 アプリケーションはそれなりにレイヤー化されています。controllerとserviceとrepositoryがある。よくある３層構造です。何を見直して再設計するのか？それはドメインオブジェクトモデルの構築です。 現状のアプリケーションはビジネスロジックをモデリングしたものとは言えない状態です。自分がやったのだけれど。しかしだからでもあります。なぜこうなったかを振り返り、どのようにできたかを考えます。失敗から学べることもあるはずです。 参照側の層は薄く？本当に？ 開発対象のシステムはある情報の検索
WEB+DB PRESS特集「体験 ドメイン駆動」を執筆しました [DDD] - little hands' lab
WEB+DB PRESS Vol.113の特集として、「体験 ドメイン駆動設計 - モデリングから実装までを一気に制覇」を執筆しました。ボトムアップドメイン駆動設の@nrslibさんとの共著です。 抽象的な解説だけでなく、実際にモデリングから実装まで行うサンプルがある こと、ドメインモデル図、サンプルコードそれぞれ4段階に分かれて改善の過程が追えるようになっている ことが特徴です。 DDDでは抽象的な議論に終始しがちなところ、具体的な事例を用いて目的や効果を理解してもらえる構成を心がけました。 構成 1章 なぜいまドメイン駆動設計か - 仕様がわかり、変更容易なコードへ 担当: @nrslibさん 「結局DDDって何がしたいの？」ということを理解できるように、従来の開発手法の問題点、ドメイン駆動設計による解決法を示します。 2章 ドメインモデリング - 現場の知識を抽出し、問題解決力の高い
![WEB+DB PRESS特集「体験 ドメイン駆動」を執筆しました [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/0b8f36d24b5140d673d31c02e8bc877632984b10/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2Fd7ff640d7e3ca2d22514a3a69fc4ab93c3ab051e%2Fbackend%3Dimagemagick%3Bheight%3D1200%3Bversion%3D1%3Bwidth%3D1200%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20191024%252F20191024080100.png)
DI コンテナと Factory パターンについて - tasuwo's notes
ただ、上記のボイラープレートでは DI コンテナが利用されていた。DI コンテナは実装する側としてはとても楽なのだけど、後から読む側としては一見分かりにくいことも多いし、具体的にオブジェクトに注入される依存がなんなのか追うのが大変だったりするイメージ (そこは実装者がちゃんと実装しろ、ということなのかもしれないが...)。 インスタンス生成のルールを切り出すなら、Factory パターンとして別に置いておく方が分かりやすいような気がして、DDD 的にはそれは (レイヤー的に) どこに位置するのだろうと思った。
DDD導入に踏み切れない方へ贈る「2層 + CQS アーキテクチャ(Flyweight DDD)」/Flyweight DDD
Flyweight DDD 軽量DDDを避けつつ軽量(Flyweight)にDDDを導入するためのアーキテクチャです。
過去の失敗例から再考するモデル駆動設計
過去に僕が失敗した代表例から今ならどう設計するか、という観点でお話します。中心になるトピックは以下です - 軽量DDDの功罪 - ドメインモデル貧血症対策 - 集約の境界定義の善し悪し
ドメイン駆動設計という設計スタイル
10. 設計スタイルの違い 2019/8/31 10 関心 モジュール構造 ２０：８０ 入出力 ドメインロジック ビジネスルールに基づく計算と判断のロジック画面、テーブル、Web API トランザクションスクリプト 画面やデータに注目して、入出力手続きを構造化 値の種類に注目して、独自の型を定義 ドメインオブジェクトモデル 11. 設計スタイルの違い 2019/8/31 11 関心 モジュール構造 ２０：８０ 入出力 ドメインロジック ビジネスルールに基づく計算と判断のロジック画面、テーブル、Web API トランザクションスクリプト ドメインロジックの設計と実装が アプリケーション全体の構造を左右する 画面やデータに注目して、入出力手続きを構造化 値の種類に注目して、独自の型でロジックを構造化 入出力の設計と実装が アプリケーション全体の構造を左右する ドメインオブジェクトモデル
「DDDのモデリングとは何なのか、 そしてどうコードに落とすのか」資料 / Q&A - little hands' lab
Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD！ コラボカンファレンス に登壇させていただいたのでで、その際の資料です。 また、当日sli.doでたくさんのご質問をいただいたので、まとめてお答えします。 発表資料 DDDのモデリングとは何なのか、 そしてどうコードに落とすのか from Koichiro Matsuoka www.slideshare.net もっと詳しく知りたい方は この発表資料の内容を、さらに詳しく解説した書籍を出しました！ little-hands.booth.pm 初めてDDDを学ぶ方、もしくは実際に着手して難しさにぶつかっている方向けの書籍になっています。 迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、 具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。 この本の「第2章
PlantUMLを通じてドメインモデル図の書き方を学ぶ - EurekaMoments
ダイアグラム別UML徹底活用 第2版 作者:井上樹翔泳社Amazon 目次 目次 はじめに プロジェクトの開始時にやるべきこと ドメインモデル図とは ドメインモデル図を描く手順 1. 「名詞」の抽出 2. モデル同士の関係を線と矢印で表す 3. 中心となるモデルに色を付ける ドメインモデル図を用いる際の注意点 ドメインモデル図の活用方法 ドメインモデル図の作成例 例1. 認証システムの場合 例2. 課金システムの場合 例3. 本屋の場合 例4. 投稿システムの場合 GitHub 参考資料 はじめに ソフトウェアの仕様書、設計書の作成や管理を効率化するために、Markdown + PlantUMLによる作成方法を日々模索しています。 しかしながら、そもそもUML図の正式な書き方というものをちゃんと分かっていないというのが正直なところなので、PlantUMLを通じてUMLの各種図の書き方を勉強
ソースコードで理解するクリーンアーキテクチャ - Sansan Tech Blog
はじめに こんにちは。プロダクト開発部の荒川です。 これまで最年少を謳っていましたが、ついに新卒の子にその座を奪われてしまいました。とても残念です。 さて今回のテーマは、皆さんお馴染みクリーンアーキテクチャ（Clean Architecture）です。 クリーンアーキテクチャは一時期流行し、その流れに乗って私もある程度の理解はしていました。 しかし、それはあくまでも感覚的な理解であって、他人に説明や良さを語れるレベルまで自分の中で落としこめていませんでした。 そこでより具体性のあるソースコードを読み込むことで、アーキテクチャへの理解を深めたいと思います。 クリーンアーキテクチャとは？ クリーンアーキテクチャの定義や解説に関しては、ネット上にいくらでも公開されているので、このエントリでは詳しく話しません。 私自身が勉強に使った書籍やサイトを記事末尾の「参照」に掲載しているので、そちらを参考に
現場でDDD！のハンズオン、持ち帰ってやってみた - little hands' lab
genbade-ddd.connpass.com こちらのイベントに参加してきました。 タイトルに「レガシーをぶっつぶせ」とあった効果か、基本レガシーに立ち向かった実体験ベースの具体的な、泥臭い話が多くて非常に楽しかったです。 DDD周りって結構抽象的な話に終始してしまうことが多いので、これほど具体的な話が集まったイベントはすごく貴重だったと思います。人数も相当集まっており相当好評だったようでまたやりたい、とクロージングで話されていたので、また次回に期待したいです。 モデリングハンズオン その中で、「DDDモデリングハンズオン」というコンテンツがあり、モデリングしながらドライバーの方がライブでコードを書いていただくというとても良いコンテンツがあったので参加してきました。 そこでは携帯の月額プランをお題にモデリングをされていました。 そこで参加した内容が時間内に終わらなかったこともあり、自分
『レガシーをぶっつぶせ。現場でDDD！』に行ってきたよメモ - コード日進月歩
レガシーをぶっつぶせ。現場でDDD！ にいってまいりましたのでメモ。 今回はDX（デジタルトランスフォーメーション）レポートに取り上げられていた技術的負債の塊であるレガシーシステムに立ち向かうためのDDDということで現場のどろどろ感を出してくイベントという趣旨。 各発表の感想 ソフトウェアの核心にある複雑さに立ち向かう 本日のオープニングで発表したスライドです。 - ドメイン駆動設計でなぜつくるのか？ - 「核心にある複雑さ」とは何か？ - その複雑さにどう立ち向かうか？ ソフトウェアの核心にある複雑さに立ち向かう #genbadeDDD https://t.co/CZYBI0Gkho— 増田 亨． (@masuda220) 2019年5月11日 感想 ソフトウェアにおける複雑さの根源に対する向き合いかた、切り分け方の考え方の話 変更容易性が高いことは開発におけるすべての面において有効とい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Amazon.co.jp: 「実践ドメイン駆動設計」から学ぶDDDの実装入門 CodeZine Digital First: WINGSプロジェクト青木淳夫 (著), 山田祥寛 (読み手): Digital Ebook Purchas
