ドメイン駆動設計という設計スタイルドメイン駆動設計という 設計スタイル ギルドワークス 増田 亨 2019.8.31 レガシーをぶっつぶせ！ 現場でDDD #genbadeDDD これから話すこと 2019/8/31 2 設計スタイルの選択 ドメインロジックに焦点をあわせる 開発現場での実験結果と考察 設計スタイルの選択 32019/8/31 設計スタイルの三つの側面 2019/8/31 4 関心の分離のアプローチ モジュール構造の考え方 ２０：８０のとらえ方 設計スタイルの三つの側面 2019/8/31 5 関心の分離のアプローチ モジュール構造の考え方 ２０：８０のとらえ方 何と何を分けるか？ 何と何を一体にするか ソースコードをどう分割し、どう組み立てるか 80%に大きな影響を及ぼす20%はどこか 設計スタイルの違い 2019/8/31 6 関心 モジュール構造 ２０：８０ 設計スタ
Qiitaのランキングの最初の設計者としての「いいね」の設計と、「LGTM」は下においてほしいという話 - mizchi's blog
https://blog.qiita.com/like-to-lgtm/ Qiitaさんの変更。思想はまぁわかるものの、「全部読んでから押してほしい」といいながら、開いた直後に押せるところに配置するのは意味がわからないかなあ。https://t.co/HEtwKg0txr— chokudai(高橋 直大)🌸🍆🍡 (@chokudai) 2020年3月12日 これについては chokudai さんに完全に同意なのですが、その理由として、自分の在職時に企画したサービス設計意図が強くあって、退職者がそれについて今更どうこういうのはどうか思うところもあるのですが、当時の同僚がほぼ全員退職してしまっているため、ここでその意図を伝えます。 お前は誰 & 何 当時の Qiita の開発で、ストックといいねを分離して、いいねをベースにしたランキングの実装のを提案したのが自分です。社内の Qiita:
本書は、初めてDDDを学ぶ方、もしくは実際に着手して「難しい！！」と感じているエンジニアの方を対象とした、ドメイン駆動設計(以下、DDD)についての解説書です。 近年、ソフトウェアのレガシー化が社会的に問題になっていると言われています。 DDDはレガシー化への対策として非常に有用なものですが、日本語で出ている書籍「エリック・エヴァンスのドメイン駆動設計」や「実践ドメイン駆動設計」は非常に重厚かつ難解で、初学者が実用に到達するまでには長い時間と試行錯誤が必要なのが実情です。 そこで本書では、迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、 具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。 また、その後にはレイヤーごとの個別のトピックについて、1章ずつ詳しく解説します。 ■本書の構成 本書は以下の構成になっています。 「第1章 DD
インクジェットプリンターの設計を変えて純正品のインクカートリッジしか使えないようにしたとして、互換品のカートリッジを販売するエレコム（大阪市）などがブラザー工業（名古屋市）を相手取り、設計変更の差し止めと約1500万円の賠償を求めた訴訟の判決が30日、東京地裁であった。朝倉佳秀裁判長は、設計変更が独占禁止法違反（不公正な取引方法）にあたると認め、約150万円の賠償をブラザーに命じた。 判決によると、ブラザーは2018年12月以降に製造・販売したプリンターについて、インクカートリッジの読み取り機能の設計を変更し、互換品を認識しないようにした。 排除は「公正な競争を阻害」 東京地裁 判決は、プリンター製造業者は、プリンター本体の価格を抑え、利益率の高い純正品のインクカートリッジを継続購入してもらうことで収益を上げていると指摘。純正品に比べ価格が安い互換品が売れれば、プリンター製造業者への経済的
回答 (3件中の1件目) なかなか理解しづらい話だと思いますが、当時のベル研究所において、Unixのグループは濃密な知のルツボだったのです。B言語が発明されるとすぐに、十数人の人々が使い始め、良かったところと悪かったところのフィードバックが集まりました。デニスは数日後にはインタプリタ言語だったB言語をコンパイラ化し、古いバージョンを分かりやすいところに置いていました。B言語のユーザーは、バグを見つけるとデニスにメールし、バグが直るまで古いコンパイラを使っていました。 B言語をC言語に改名した主な理由は2つあります。まずB言語(とBCPL)は、CPUのアドレスがバイト単位ではなくてワード...
はじめに HTML＋CSSコーディングにおいて、「どのように要素を特定してスタイリングするのか」というCSS設計上の課題に対し、「ひとつ上の視点で思考できる概念図」を紹介します。 この図を用いることで、3種類の異なるスタイリングアプローチ（OOCSS方式 / 包括要素基点方式 / BEM方式）の本質を一度に俯瞰できるため、全てを同じ枠の中で捉えられます。そして、最終的には種別や規模の異なるサイトやプロジェクトに対し、同じメソッドを使ってそれぞれ最適な設計がおこなえるようになります。 ※この記事は標準化ノウハウ公開の一環として書いています。 仕組みの概要や前提事項などについては「UltimateCoding 概要・前提事項」のエントリをご確認ください。 経緯 / 制作者中心のデータ分類 そもそもですが、HTMLとCSSは目的も仕様も異なる言語です。 HTML+CSSコーディングを一般的な視点
煽りじゃなくてマジでこれ 賃貸から要望出しまくった注文住宅に引っ越したら何も困らなくなった 男性設計士も考えてないわけじゃないんだが 片付ける側の発想ではなく、片付けてもらう側の発想で設計しているんだよね システム開発に例えるとユーザーを誘導する設計ではなく、ユーザーが勝手にうまく使ってくれると想定して設計している感じ 賃貸や建売では不可能な収納術 ものの定位置を決める 出したら出しっぱなしの人でも定位置があると片付ける確率が上がる必要なものは必要な場所の近くに収納する でかい収納だと必然的に必要な場所から遠ざかる。小さい収納を複数用意する収納との距離が近づくほど出したら出しっぱなしの人でも片付ける確率が上がる収納ボックスのサイズに合わせる ホムセンでもニトリでもいいけどサイズをきっちり合わせる見た目が整うほど出したら出しっぱなしの人でも片付ける確率が上がるできるかぎり玄関で済ませる 上着
コーナンの作業台、コストカットの鬼みたいな薄い鉄板性だけど脚のプレスの入れ方に驚いた「これどんな神が設計したんですか？」【追記あり】
Akihiro Komori @comocc コーナンの作業台買ったんです。薄い鉄板で出来ててコストカットの鬼みたいな雰囲気。なんだけど、この脚のプレスの入れ方をみて驚いた。これどんな神が設計したんですか？この加工だけで強度と安定性爆上がりですよ。大学は機械系だったけど、こんなの授業じゃ習わなかったなあ。惚れ惚れする。 pic.twitter.com/vMDuBeXdJ6 2024-04-17 10:32:24
服さん @fukusanity 尻のデザインすごくて、中心に肛門っていうウンチが出る穴があるんだけど、普通なら蓋みたいな構造にしてしまいそうなところを2つの肉の塊でギュッと包むことで穴を塞いでるんですよね。蓋みたいな構造だと汚れが溜まりそうだし、ウンチ出す前に蓋を開ける手間が発生するんだけど、考えた奴は賢すぎる 2023-12-26 23:20:25 服さん @fukusanity 「2つの肉を挟み込む穴の開閉構造（以下: 肉挟み込み開閉構造）」は水でジャーっと洗えば汚れを落とせるしガチですごい．だからこそ肛門はヒンジを伴う蓋の構造ではなく，肉挟み込み開閉構造が採用されたのでしょう．この仕組み口部にも採用されており，恐らくですが特許を押さえていますね 2023-12-27 09:59:49 服さん @fukusanity この前これに気付いて「現状の尻を超える尻の設計は無理だ」と思った。そ
※リンクを効かせたい場合はダウンロードしてください
Rails 設計 最強
自分が目指したいRailsアプリの形とは何か、ということについて考えていた。 常日頃から考えていたRailsアプリでの不満をこの議論に合流させた結果、「Rubyを書くときに当たり前にやるようなことを、Railsアプリを書くときでも当たり前のようにやる」というところが肝で、自分が目指したいRailsアプリの形はその先にあるのではないか、と一旦結論付けてみることにした。 「普通にRubyでコードを書くときはやらないけど、Railsだったらこう書く」という何かが存在していることが、さまざまな失敗の原因をつくっていると思う。 RubyとRailsが地続きに繋がっていないというか、どこかで断絶があり、そこから筋の悪い設計が生まれている ―あるいは持ち込めるはずの良い設計を持ち込めていない― のではないか、という話。 実際にはどの辺りが気になっているのか？という例を挙げると、氷山の一角を指摘するだけな
エンジニアの採用はすごく難しい状況です。エンジニア採用ニーズが多いのに、エンジニアがやる仕事の内容も難しくなってきており、幅も広がってきています。CTO自らが真剣に向き合って考えていく必要があります。 そして、せっかく採用したエンジニアには、長く働いて欲しい、仲間として最高のパフォーマンスを出して欲しいと思います。そのため報酬設計は重要な部分となります。 報酬設計の２つの側面 １．外的報酬 外的報酬といえば、賃金、給与が先ず思い浮かびます。その他にはポジション、地位も報酬の一つと考えられるでしょう。部長や本部長等の役職がつくと社外で名刺交換した時にも見栄えが良くなります。 他にも手当てや秘書がついたり、経費の枠が増えたりと色々とあると思います。 ２．内的報酬 仕事そのものやりがい等です。楽しい仕事と思えていればやる気も湧いてくるし、難しいと思うとやり甲斐を感じる人もいます。エンジニアの場合
任天堂が2020年8月6日に公表した2021年3月期第1四半期の決算でとてつもない数字をたたき出しました。売上高は前年同期の2倍以上にあたる3581億円（108.1%増）、営業利益に至っては前年同期の6倍に近い1447億円（472.7%増）という驚異的な数字です。まさに圧倒的といってよい好業績です。
クラスをイミュータブルに設計するパターンの紹介 ・閉じた操作 ・withメソッド ・イベントリポジトリ＆集約ファクトリ
人工衛星の運用を支えるクラウドネイティブ民主化への取り組み / Efforts toward cloud-native democratization for satellite operations
【React/Vue.js】コンポーネント設計の（個人的）ベストプラクティス | Offers Tech Blog
概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。今回は、React や Vue.js などの SPA フレームワークにおけるコンポーネント設計について紹介します。 昨今のフロントエンド開発では、コンポーネント指向での開発がスタンダート化しつつありますが、コンポーネント設計には厳格なルールが無く、どのように設計すればいいか悩む方も多いのではないでしょうか？（筆者は沼にはまりました） コンポーネントの単位はどの程度に分割すべきなのか、状態管理はどうすればいいのか、API 通信はどこですべきなのかなど、一言にコンポーネント設計と言っても考えるべき項目が多いです。チーム開発では、認識があっていないとコードが魔境になることもしばしばあると思います。（筆者の経験談より） そこで今回は、数々
はじめに この記事はサービスを爆速で作ったり、ドメイン駆動設計の解説をするようなものではありません。 ドメイン駆動設計の勉強をしていて、手を動かす機会が足りないと感じていました。そこで、今の理解で実際に動くシステムをドメイン駆動で開発してみようと思いました。 本記事はその開発の過程や考えていたことを記録したものです。 「この人はこういう形に落とし込んだんだな～」くらいで見ていただけたらありがたいです。 作成するシステム 今回作るのはTODO管理システムです。 初回の開発では以下の機能を開発しました。 TODOのタイトルと詳細を登録できる 作成したTODOを検索できる 選択したTODOの詳細を確認、完了、削除ができる デモ デモなのでメールの確認はダミーです。新規登録をしたら画面に出るメール確認リンクを踏めば確認済みとなります。 その後右上のログインからログインしてください。 デモのデータベ
いつの世も人々は権限設計に苦しめられている。そうは思いませぬか。 ご多分にもれず、ぼくも note に入ってからというもの AWS の権限設計をどうしてやろうかと、あれこれ思い悩みまくった人間でした。 組織が変われば権限も変わる。誰が何をしたいのかなんてとても把握しきれないし、かといって全員に Administrator を割り振るような豪胆さも持ち合わせておらず。組織再編が繰り返される中で、なんとか運用に耐えうる設計を考え、実装しようと試みた内容をまとめたのがこの note です。 note 社における AWS 権限設計の変遷と、その結果生まれた自動で AWS の権限を払い出す仕組みについて書いていきます。 ※この記事はnote株式会社 Advent Calendar 2022 の 25 目の記事です。 注意事項つらつらと書き連ねていたら 12,000 字超の大作 note となってしま
『良いコード／悪いコードで学ぶ設計入門』を一歩深める読み方 / deepen good code bad code
こちらのイベントで用いたスライドです。 『良いコード／悪いコードで学ぶ設計入門』を一歩深める読み方 - FwLibrary #11 https://forkwell.connpass.com/event/264759/ 動画のアーカイブはこちら。 https://youtu.be/_qXG06v8HAI
テスト自動化の成果をどう評価し、どう次につなげるか/Test Automation Next Step
【Unit4 ブログリレー4日目】 こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 今回は、SNSではごく一般的ないいねとその通知機能をDynamoDBを利用して実装したら思ったより大変だったので、その詳細をご紹介します。 キャナルシティ劇場は、福岡県福岡市博多区の複合商業施設「キャナルシティ博多」のシアタービル最上階に位置する劇場。本文には特に関係ありません。 m3ラウンジ m3ラウンジのいいねとその通知の要件 RDBで実装したらどうなるか いいね機能 通知機能 DynamoDBで実装する いいね機能 通知機能 いいねする いいねを取り消す 通知を表示する 未読の通知の取得 未読の通知数 未読の通知を既読にする テーブル設計むずい PKとSKに何を選ぶか LSIは途中から作れない DynamoDBをローカルで動かして設計する まとめ We are h
生成AI時代におけるUXデザイン | 生成AIをフル活用したUX設計手法＆生成AI時代のユーザー体験の変化について
ChatGPTやStable Diffusionなどの生成AIが急速に発展し、社会全体が大きく変化しようとしている。 UXデザインのプロセスや、UX自体のあり方も当然革新されていく。 今回はそうした生成AIによってUXがどう変化していくかを、具体的なメソッドや未来洞察といった具体・抽象を行き来しながら話していく。 1. 生成AIを活用したUXデザインプロセス どのようにGenerative AIを活用すれば、UXデザインのプロセスをよりなめらかに、効率的にすることができるのか？ 2. 生成AIでUX自体がどう変化するか Generative AIの発展によって、プロダクトにおけるユーザー体験のあり方はどのように変化していくのか？ 3. AI時代のデザイナー/PdM生存戦略 AI時代に、デザイナーやプロダクトマネージャーなどの個人はどのように強みを磨いていけばいいのか？ ▼ スピーカーTwi
設計の「why」を言語化できる人は強いんですよ— magnoliak🍧 (@magnolia_k_) 2022年10月29日 っていうか、驚くくらい「why」が上手く表現できないんですよ、普通は 手順は言えても、なぜ？が言えない— magnoliak🍧 (@magnolia_k_) 2022年10月29日 設計において、すべての決定について仔細に「なぜ、そうしたか？」を言えるべきなのだけど、これを上手く言語化できない人は多い。「このプロジェクトでは以前からそうしているから」「そうするのが当たり前だと思っていた」などなど、本当に理解してないまま「設計という作業」を進めている人もいれば、上手く自分の行為を言語化できないだけの人もいる。 また、必ずしも自分が設計したことについて説明する場面ばかりとも限らない。既に存在する設計から「なぜ」を類推するしかない場面もある。他人のコードを読み取るとき
木曽崇@国際カジノ研究所：飯テロ警報発令中 on Twitter: "政府のいう「氷河期世代の人生再設計」は「今から結婚して子を成せ」なんて話ではなく、実は「生活保護に頼らず静かに死んで行け」って意味です。 氷河期世代の人生を本当に心配しているなら、とっくの昔に動いてる。今更動き始めたのは、氷河期世… https://t.co/Rw3O9BHdad"
政府のいう「氷河期世代の人生再設計」は「今から結婚して子を成せ」なんて話ではなく、実は「生活保護に頼らず静かに死んで行け」って意味です。 氷河期世代の人生を本当に心配しているなら、とっくの昔に動いてる。今更動き始めたのは、氷河期世… https://t.co/Rw3O9BHdad
特徴 女性らしいイメージがやや多い 下記のような柔らかい印象のイラストが多いです。 【ガジェットストック】 ガジェット関連のものを使用したい場合は、下記を使用すると良いと思われます。 【アイコン系】 【human pictogram 2.0】 オリンピックで流行ったやつです。 本サイトでは、アタッチメントをつけたりすることでかなりカスタマイズ性が高いのが特徴です。 【EXPERIENCE JAPAN PICTOGRAMS】 特徴 海外から見た日本が表現されている これはシンプルにUIが凝ってたので紹介します。 和テイストを演出したい場合は、良さそうですね！ 【ICOOON MONO】 こちら色・サイズも変更可能です！ 【Icon-rainbow】 ICOOON MONOと異なり、こちらは、中が肉抜きされているのが特徴。 【IFN FREE ICONS】 このデザインはどのようなパターンにマ
リンク www.city.himeji.lg.jp 姫路市｜姫路城公式ホームページ（姫路城大図鑑） 姫路城特設サイトです。姫路城周辺の駐車場（車・バイク）の案内、姫路城の概要などを掲載しています。 8 users 2425 リンク Wikipedia 姫路城 姫路城（ひめじじょう）は、兵庫県の姫路市にある日本の城。江戸時代初期に建てられた天守や櫓等の主要建築物が現存し、国宝や重要文化財に指定されている。また、主郭部を含む中堀の内側は「姫路城跡」として国の特別史跡に指定されている。また、ユネスコの世界遺産リストにも登録され、日本100名城などに選定されている。別名を白鷺城（はくろじょう・しらさぎじょう。詳細は名称の由来と別名を参照）という。姫路城は播磨国飾東郡姫路、現在の姫路市街の北側にある姫山および鷺山を中心に築かれた平山城で、日本における近世城郭の代表的な遺 27
在華坊 on Twitter: "倫理的な側面や安全的な側面から宇崎ちゃん献血コラボキャンペーンのインセンティブ設計を否定する論調、正直、程度問題をゼロイチで論じるような、放射能問題で散々見てきたような詭弁としか思えないので、まったく賛同できません。キモいならキモいとだけ言えよ"
倫理的な側面や安全的な側面から宇崎ちゃん献血コラボキャンペーンのインセンティブ設計を否定する論調、正直、程度問題をゼロイチで論じるような、放射能問題で散々見てきたような詭弁としか思えないので、まったく賛同できません。キモいならキモいとだけ言えよ
悪いコードをやっつけよう！『良いコード/悪いコードで学ぶ設計入門』を読んで - 虎の穴開発室ブログ
こんにちは。虎の穴ラボのH.Kです。 5月の大型連休で社内の技術書購入を支援する制度を利用して購入した『良いコード/悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方』を読みました。 『良いコード/悪いコードで学ぶ設計入門』書影 とても良い本でしたので、本書の横断的な概要と、その中で良かったところや気になったところをご紹介していきます。 どんな本か 基本情報 私が感じた本書の立ち位置 前提 設計とコーディングは不可分である 「悪いコード」=>「良いコード」の構成 サンプルコードはJava おすすめする読者層 著者について 構成について 1〜2章：チュートリアルステージ 3〜12章：本編 13〜17章：やりこみ世界 良かったところ 平易な表現 サンプルコードが豊富 気になったところ 6章：Switch文の重複（Switch文からMapへの書き換え） まとめ P.S. どんな本
最初にマイルストーンを切って、この週で設計、この週で実装、みたいなことをやるのはおすすめできない。 設計に使える時間を最初に決めた時間までしか使わないということは、どうすればいいか、考えきれてなくても作り始めているということ。 コードは書けていくので、進んでいるようにも見えるけど、問題を先送りしているだけなので、じっくり設計や作戦を詰めていれば気付ける問題に、あとのほうで直面することになる。 この問題を回避するためにはこのように作るべきであった、ということにあとで気づくと手戻りが大きくなり、こんなことをするくらいなら最初に決めておけばよかった、となることが多いと思う。 家を建てることをイメージすると、設計フェーズはここで打ち切って、手を出せるところから始めよう、といきなり柱を建てることをイメージしてほしい。 先のことを見据えると、4本の柱は長方形になっているべきという制約があるけど、そのこ
テーブル設計を遅らせることでユーザー体験の最大化を狙える!?米国式最新開発手法「ADD」とは。。 - Qiita
初めまして、記事に訪問いただきありがとうございますm(_ _)m 今までのプロジェクトでありがちな言い訳。。。 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります なんでこんなことが起こってしまうのか もう15年も前になるPOA vs DOA論争の結果、データ整合性のためにテーブル設計を一番初めに済ませることが一般的になりました。 【初級】ゼロから学ぶDOA 第1回 ですがこのやり方では実際の画面の動きをお客様が見る前に仕様を決めて、 そ
この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事
![CQRS実践入門 [ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/fe5018ad772252621db406116ce62131478fb6b1/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20191202%2F20191202061944.png)
RESTful のウェブ API 設計で避けるべき 6 つのよくあるミス | Google Cloud 公式ブログ
※この投稿は米国時間 2022 年 12 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。 もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便
ドメイン駆動設計に取り組んだ事例をもとに以下の点について説明しました。 1. ドメイン駆動設計とは一体何か？ 2. どんなメリットがあるのか？ 3. ドメインモデルについて 4. 設計パターンについて 5. ドメイン層の隔離について
みずほフィナンシャルグループ（FG）が2021年に入り6度のシステム障害を起こした問題で、新システムの総点検やバックアップが機能しない場合の復旧手順の整備などを盛り込んだ報告書の全容が明らかになった。原因はなお特定できておらず、巨費を投じて開発した新システムが「当初想定した設計となっているか点検を検討する」としている。報告書はおよそ50ページにのぼる見通しで、障害が起きた原因と再発防止策、障害
23新卒技術研修で実施したテスト・設計研修の講義資料です。 動画：https://youtu.be/xR-LWJ4MAEM 資料の利用について 公開している資料は勉強会や企業の研修などで自由にご利用頂いて大丈夫ですが、以下の形での利用だけご遠慮ください。 ・受講者から参加費や授業料などを集める形での利用（会場費や飲食費など勉強会運営に必要な実費を集めるのは問題ありません） ・出典を削除または改変しての利用
DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡です。 本記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、本記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p
![DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/e19eb6aae8a33a9c7d58ab11012b9b1e4fd3dc14/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20210306%2F20210306230551.png)
こんにちは、delyコマース事業部エンジニアの小川です。 先月11月に入社し、エキサイティングな毎日を過ごしています。 この記事はdely Advent Calendar 2019 - Qiitaの24日目の記事です。 昨日はSREの松嶋さんが「AWS RunCommandを使ってEC2上に監視ダッシュボードをサクッと作る（Ansible+Terraform+Grafana編）」という記事を書いてくれましたので是非そちらも読んでみてください！ tech.dely.jp コマース事業部では、現在「事業開発」と「ソフトウェア開発」がほぼ同時に進行しており、プロジェクトにおける確定要素と不確定要素が複雑に絡み合っています。 スピード重視でゴリゴリ実装していくのも興奮しますが、変化に耐えづらい実装をしてしまうと、その後の開発スピードに影響していまい、事業のスピードが落ちるなんて事にもなりかねません
RESTful APIのリソース設計で述べた通り、何をリソースとするかを決めたらそのリソースを識別するURIを検討する必要がある。 エンドポイントとは何か エンドポイントとはAPIにアクセスするためのURIのこと。例えば、QiitaのAPIで自分の情報を取得する時のエンドポイントは以下となる。 http://qiita.com/api/v2/users/nagaokakenichi 似たような言葉に「エントリポイント」というものがある。エントリポイントとはプログラムやサブルーチンの実行を開始する場所のこと。 Qiita視点で考えると、 http://qiita.com/api/v2/users/nagaokakenichi を参照されることでプログラムが開始されるので、Qiitaからすると上記URIはエントリポイントとなる。 つまり、エンドポイントはAPIにアクセスする側からの、エントリポ
GraphQLのよいスキーマ設計についてです。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン駆動設計という設計スタイル
ドメイン駆動設計 モデリング/実装ガイド - little-hands - BOOTH
インク互換品、使用不可の設計「違法」 ブラザーに賠償命令：朝日新聞デジタル
なぜC言語は、B言語を継承して、1から設計し直さなかったのでしょうか？
1段上のCSS設計・コーディングの概念図（HCDCモデル図） - Qiita
収納がうまくいかないのは家事をしない男性が設計した家に住んでいるから
ある日、肛門という部位のデザインは特許レベルだと気付き「現状の尻を超える尻の設計は無理だ」と心底思った
"クラウドアプリケーション 10の設計原則" をもっと楽しむ
エンジニアマネージャー必見：報酬設計の考え方 - Qiita
売上高2倍・利益6倍の超ヒット任天堂あつ森「非常識すぎる」設計
ドメイン駆動設計とイミュータブルなクラス設計
金融系サービスで ECS/Fargateを設計するということ
とにかくドメイン駆動設計を実践してみる試み ～TODO管理システム編～
note 社の AWS 権限設計の変遷を辿る｜かとうかずや | kakato
テスト設計チュートリアル/Test Design Tutorial
いいねとその通知機能をDynamoDBで設計したら思ったよりムズい - エムスリーテックブログ
設計の「why」を言語化する - Magnolia Tech
【爆速UI設計術】モダンなwebデザイン素材集 - Qiita
姫路城さん、駅を出た瞬間の景色で「鋼の意志」が感じられると話題に「親切設計すぎる」
高速周回が迷わずできる！ 「ウマ娘」UI設計の根幹とは 大量の情報でも「整理とルール化」でわかりやすい画面を作る
時間を区切って設計を打ち切るのはおすすめできない - hitode909の日記
CQRS実践入門 [ドメイン駆動設計] - little hands' lab
俺たちのドメイン駆動設計はこれからだ！
みずほ報告書の全容判明、システム「設計通りか点検」 - 日本経済新聞
テスト・設計研修【MIXI 23新卒技術研修】
~OSSから学ぶ~ MVCフレームワークの保守性がモリモリ上がるクラス設計 - dely Tech Blog
RESTful APIのURI設計(エンドポイント設計) - Qiita
はじめてのGraphQLスキーマ設計