ドメイン駆動設計(DDD)を整理
またクラスを利用していないため、オブジェクト指向の特性「継承」「カプセル化」「ポリモーフィズム」は利用していません。この部分が厳密なドメイン駆動設計(DDD)のニュアンスと異なるので「風味」という言葉を使っています。 全体概要と用語の整理 まず初めにドメイン駆動設計の全体の概要と出てくる用語について紹介します。 自分は言葉を理解しないとコードの理解に落とし込めなかったので詳しく解説をしていきます。 各用語の具体的な実装は後の章で紹介します。 すべての用語において理解しやすいように「ユーザー管理システムを実装する」例を用いて解説を入れています。(解説の都合で書籍とは異なる例を採用しています) ドメイン駆動設計とは ドメイン駆動設計はその名の通り、「ドメインの知識」に焦点をあてた設計方法 「ドメイン」とは、ソフトウェア開発におけるプログラムを適応する対象となる領域 ドメインについて ドメイン駆
「クラスごとの役割を明確化すること」がポイント アプリケーション設計におけるドメインロジックの分離法
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。続いて、Controllerにプレゼンテーション層からデータアクセス層の処理をすべて記載している場合の分離方法について紹介します。前回はこちらから。 質疑応答 ドメインモデルパターンはドメイン騒動設計と同義か？ 大嶋勇樹氏：ということで、ここまでビジネスロジックの実装について話してきました。ここからは最後のステップとして、「Controllerに全部書く」からどうやってステップアップするかを話していこうと思います。 ここまでで質問があれば、ぜひQ&Aにもらえれば回答します。せっかくなので、このタイミングで「ドメインモデルパターンはドメイン駆動設計と同義ですか？」（という質問）に回答しておこ
Kubernetesのキャッシュネームサーバとリゾルバ | IIJ Engineers Blog
ただ、サーチリストがこうなっているのは利便性のためだけではなく、もっと切実な理由があります。 サーチリストとndots DNSの一般的な名前解決のルールとして、こんな風に覚えている方もいるかもしれません。 名前にピリオドが含まれていたら、FQDNとみなしてサーチリストを参照せずに名前解決を行う 名前にピリオドが含まれていなければ、サーチリストのドメインを末尾に連結して名前解決する 例えば、こんな具合です。 $ ping myhost # ピリオドが含まれていないため、myhost.example.comが名前解決される PING myhost.example.com (192.168.0.1) 56(84) バイトのデータ 64 バイト応答 送信元 myhost.example.com (192.168.0.1): icmp_seq=1 ttl=57 時間=12.4ミリ秒 $ ping w
2023に給料を上げたいソフトウェアエンジニアの勉強方法｜gaijineers
来年こそ年収1000万以上狙いたいなら自分はこうする 面接の種類多すぎるので全部準備すると時間かかるので同じ面接タイプの企業を複数受けるのがコツです。 同時に勉強する勉強する大半給料の高い面接はコーディングテストあるのでleetcodeは必ずやる。leetcodeの練習は続くのが大事で1ヶ月に300問をやるぞというより1ヶ月に30問をやった方が覚えるしモチベーションが続く。 leetcodeの軌跡一日中leetcodeやるのは効率悪くなるのでドメイン知識のインプットしながらやっていく。学校の授業も一日中ずっと数学をやるのではなく複数科目をやっているのと同じ理由です。Spaced and Interleaved practiceの意識が大事 LeetCode最低限100問やってIDE補完やdocumentationなしでLeetcode mediumを解けるぐらいにしとく。 シニアレベルをも
転職活動でいろんな会社のマイクロサービスと組織を見聞きして思ったこと - Runner in the High
転職活動でいろんな会社のエンジニアの人と話して思ったことをマイクロサービスの観点で備忘録がてらメモしておく。 よくあるマイクロサービスの分割軸として、業務機能、ユースケース（動詞）、リソース（名詞）あたりが一般的だが、これらどれもがドメインを構成する要素であるため、マイクロサービスに分割してしまうと結果的にソフトウェアの形がビジネスルールの変化を制限してしまうケースの方が多い気がしていた。実際、規模の小さい開発組織でマイクロサービスやってみました〜からのツラミはそういうのが多いイメージで、よくある「マイクロサービスやったけど逆に開発遅くなった」みたいなとこは上で挙げたような粒度の切り方をしている印象がある。 この件に関して、去年末の転職活動のタイミングでいろいろな人に話聞いてみた結果、実際にマイクロサービスでうまくやっていそうな組織は、上で書いたようなドメインを構成する要素でマイクロサービ
ドメインモデルの完全性と純粋性 - kawasima
ドメインモデルには、完全性と純粋性、そしてアプリケーション性能の3つ全てを同時に満足させることは難しい場合があるという話。
ドメイン駆動設計（DDD）で開発されたシステムを5ヶ月保守開発した感想・学び - Qiita
巷で、顧客の課題を解決しつつ、より良いシステムを作るための設計手法として、ドメイン駆動設計（DDD）が話題になっていると思います。 このドメイン駆動設計について、どのように実践するか、実際に実践してみてどう感じたか、という話はよく出ていますが、作られたシステムがその後どのようになったのか、保守開発した結果どう感じたのかの話はあまり聞かないな、と思ったので、自分の経験から「実際のところどうなんだ」というところを振り返ってみようかな、と思い、今回の記事を書きました。 目次 私が保守開発しているシステム 5ヶ月の間にやったこと 保守開発していて感じたこと よかったこと 改修時に修正箇所が特定しやすかった テストコードが書きやすく安心して保守することができた 成長できたという実感があった 難しかったこと、学び ドメイン知識は次第に流出していく 定期的なメンテナンスが大事 最後に おまけ エンジニア
DDD本を読むためには前提知識が非常に多いよ - Qiita
初めに きっかけ 新人研修中にDDDとか、PoEAAとかの話が少しだけ出ました。 ただ、イマイチわからないとの声が多数。 理由 なぜなら予備知識がたくさん必要だからです。(ほんとに多い) これはわからなくて当然。 そこで 独断と偏見で、予備知識となる用語を解説します。 偏見多いので、より正確な情報は、書籍やWebで調べてね。 この辺を説明します UML クラス図/シーケンス図 デザインパータン GoF/PoEAA 階層化アーキテクチャ DDD本のサマリ 知らなきゃいけない知識が多くて面倒だね。 説明しないけど、オブジェクト指向やデータベースとかの知識も必要だよ。 説明前にDDD本のページを見てみよう！！！ DDD本の最初のページ 「エリック・エヴァンスのドメイン駆動設計」より ??? よくわからないね さっきの図って何? 灰色の中心部分はソフトウェア設計のモデリングを表しています。 モデリ
Domain Modeling Made Functional を読んだ - 詩と創作・思索のひろば
最近フロントエンドに限らず TypeScript を書くことが多くなって、これでそれなりの規模のサーバサイドアプリケーションを書くときどうなるんだろう、と気になって読んでみた。いわゆる普通のオブジェクト指向ではなく関数指向な書き方でいきたいとき、どうするのが好ましいのか、というような観点。 名前的にそのものずばり、という本があったので購入した。日本のウェブを検索してみてもいくらか言及があるので価値はありそうだという判断で、大人なので円安でも強行する。 Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition) 作者:Wlaschin, ScottPragmatic BookshelfAmazon 自分は PDF で読みたかったので
MFA（多要素認証）を突破するフィッシング攻撃の調査 | セキュリティ研究センターブログ
はじめに 弊社では、最近BEC（ビジネスメール詐欺）のインシデント対応を行いました。この事案に対応する中で、マイクロソフト社（*1）やZscaler社（*2）が22年7月に相次いで報告したBECに繋がる大規模なフィッシングキャンペーンに該当していた可能性に気づきました。マイクロソフトによると標的は10,000 以上の組織であるということから、皆様の組織でもキャンペーンの標的となっている可能性や、タイトルの通りMFA（多要素認証）を実施していたとしても、不正にログインされる可能性もあり、注意喚起の意味を込めてキャンペーンに関する情報、および実際に弊社での調査について公開可能な部分を記載しています。 *1: https://www.microsoft.com/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm
データモデルはドメインモデルに先行する - 設計者の発言
関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD（ドメイン駆動設計）に関心を持つ技術者にとってお手本になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。 どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。 これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させ
フロントエンドエンジニアが「自分はJSON色付け係」と自虐する理由を考察した - パンダのプログラミングブログ
「JSON色付け係」という自虐 フロントエンドエンジニアの間では、「私の仕事は JSON に色を付けることです」という有名な自虐ネタがある。 おそらく初出は以下のツイートなのだろう（*1）。ただ、出典はあまり詳しく調べていない。 初めてこの言葉を見た時、面白い言い回しだなと思った。確かにフロントエンドの仕事にそういう側面はある。 実際、コンテンツの表示がメインのページで作業すると上記のような気持ちになる。この場合、フロントでやることといえばせいぜい日付の表示形式を適切にフォーマットするくらいだ。結局バックエンドからデータが返ってこないとフロントだけでは何もできないと思うこともある。 もちろん、フロントだけで簡潔する手書き風グラフ作成ツール excalidraw のようなものは別だし、フロントで複雑な状態を扱う部分を書いたり、フォームを使ってユーザー入力を受け付け、入力値を検証するバリデーシ
簡単にできるDDDのモデリング - ドメイン駆動設計 - little hands' lab
DDDではよく「モデリングが重要だ！」と言われますが、どのようにモデリングすればいいのかがわからず、一歩を踏み出せないことは多いのではないでしょうか。 そんな方のために、本記事ではDDDにおいてシンプルで成果が出しやすいモデリング手法について紹介します。 (本記事は、YouTube動画「10分でわかるドメインモデリング」の内容をもとにした解説記事です。) DDDの目的 DDDの目的から確認しましょう。 DDDの目的は2つ。 ①機能性を高めること これは、役に立つものを作ること、言い換えると「作ったけど使えない」を避けることです。 そのために、ドメインモデリングを行い、ソフトウェアを適用して役立てようとしている現実世界の領域(これの領域をDDDでは「ドメイン」と呼びます)について理解を深め、解決策を検討することを目指します。 ②保守性を高めること これは、長期間開発しても機能拡張が容易であり
メモ:値オブジェクトの定義と差異について - かとじゅんの技術日誌
「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。 すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。 もし読むなら興味がある人だけで。 自分向けのメモですが、一応 この記事の前提や意図を書いておきます。 「DDDの値オブジェクト」以外を否定する記事ではありません。 原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか 下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。 言い訳と
ドメイン固有型(値オブジェクト含む)を再考する - かとじゅんの技術日誌
Value Objectが盛り上がっているらしい。 Value Objectについて整理しよう - Software Transactional Memo Value Objectの説明に異論がないものの、主題はValue Object Obsessionのほうですよね。 こちらも聞いてみた。 fukabori.fm よい機会なので、よくわかっているつもりの、値オブジェクトというかドメイン固有型について再考してみよう。 それは値か属性か それはエンティティの全メンバーやデータベースの全列のために「顧客郵便番号」「送付先郵便番号」「事業所郵便番号」「契約日」などのクラス(メンバではなくクラス！)を定義して、immutableな振る舞いを強制する事を以てValue Objectであると言い張り、ドメイン知識の断片をそれぞれのクラスに書き散らして「高凝集になった」「型システムが守ってくれる」と喜
Value Objectについて整理しよう - Software Transactional Memo
Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a
CUPID—for joyful coding
What started as lighthearted iconoclasm, poking at the bear of SOLID, has developed into something more concrete and tangible. If I do not think the SOLID principles are useful these days, then what would I replace them with? Can any set of principles hold for all software? What do we even mean by principles? I believe that there are properties or characteristics of software that make it a joy to
★★再追記 レンタルサーバは、自由度が低くてストレスになるからやらない..
★★再追記 レンタルサーバは、自由度が低くてストレスになるからやらない。SQLでwith使いたいからMySQL8をって言ってもさくらレンタルサーバじゃ無理なんでしょ？ あと同居利用者のせいで高負荷ってのも避けたい。そこを気にしない人はレンタルサーバでいいと思うよ。 あと LB $0.025/h だった。月2000円くらいか。 ★追記 LBは独自ドメイン+自動更新無料SSL証明書のためね。Cloud Storageの無味乾燥なドメインでいいなら、SSL自動かつ無料でほんとに月数円。 －－－－－－－ もうねめんどくさいんだわ。もちろん以前はそうやってたよ。 PHPだのApacheだのMySQLだのインストールしたり設定ファイル置いたり、 脆弱性対応したり、SSL証明書更新したり、一応落ちてないか無料監視サービス使ったり。 でも仕事ならともかく、趣味だからこそこんなことやりたくないじゃん。 なの
DDDで開発する際におさえておきたい4つの基本事項
DDDで開発しようと思って、入門書を勉強して理解した気になっても、いざコードを書こうとすると、なかなか実装のイメージがつかなくて手が止まる、といったケースはあるかと思います。少なくとも、私はそうでした。 この記事では、一旦、DDDのモデリングの部分は置いておいて、コードを実装する上で知っておいた方が良さそうなことをいくつかピックアップして紹介していきたいと思います。いずれも基本的な内容のため、DDDを習得している方にはあまり新しい発見はないかもしれません。 なお、例として用いる言語はTypeScriptです。 DDDで実装してみてなにが良かったか 本題に入る前に、まずはDDDで実装するモチベーションを上げていただくために、実際にDDDで実装してみてよかった点をいくつかあげます。 ロジックを書く場所に悩まない・チームで統一できる 例えばMVCなど、ドメイン層を用意しないアーキテクチャで実装し
サブドメインをユーザーホスティングサイトに使うときのパターン(Same Origin/Cookie/Public Suffix List)
README.md サブドメインをユーザーホスティングサイトに使うときのパターン hoge.example.com でユーザが作成したサイトをホスティングして、任意のJavaScriptを実行できる状態にしたいケース。 サブドメインを分けることで、Fetch APIなどはSame Origin Policyを基本にするため、別のサブドメインや example.com に対するリクエストなどはできなくなる。 一方で、CookieはSame Origin Policyではない。 デフォルトでは、hoge.example.com から example.com に対するCookieが設定できる。 これを利用したDoS(Cookie Bomb)やこの挙動を組み合わせた別の脆弱性に利用できる場合がある。 The Cookie Monster in Your Browsers - Speaker Dec
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
