Office 365でToやCcを空にして、Bccに複数のメールアドレスを指定すると全てのメールのヘッダにBccの最初のentryのドメインネームが漏洩。MSは直す気無し。RFC的に誰の責任か不明との意見が。またHNにはMSは必ず… https://t.co/hIk599tfkk
この記事は、著者の許可を得て配信しています。 Is Domain-driven Design overrated? ドメイン駆動設計(DDD)は、システムのモデリングと構築のための優れたガイドラインを提供する大変便利なアプローチですが、それ自体が目的ではなく、目的のための手段です。その概念は有効ですが、それを使うことだけに限定すると、その一方で多くのことを失うことになります。つまり、実際にはDDDの先にも人生があるということです。 最近、「DDD は過大評価されている」というクリックベイトなタイトルの記事を投稿したところ、皆様からかなり注目を集めました。今回の記事は、社内やソーシャルメディア(TwitterやHacker Newsなど)で受けたフィードバックを取り入れて、前回の記事に内容を加えたものとなっています。また、私の考えにもう少しニュアンスを加えたかったので、あまり過激なものにはし
巷で、顧客の課題を解決しつつ、より良いシステムを作るための設計手法として、ドメイン駆動設計(DDD)が話題になっていると思います。 このドメイン駆動設計について、どのように実践するか、実際に実践してみてどう感じたか、という話はよく出ていますが、作られたシステムがその後どのようになったのか、保守開発した結果どう感じたのかの話はあまり聞かないな、と思ったので、自分の経験から「実際のところどうなんだ」というところを振り返ってみようかな、と思い、今回の記事を書きました。 目次 私が保守開発しているシステム 5ヶ月の間にやったこと 保守開発していて感じたこと よかったこと 改修時に修正箇所が特定しやすかった テストコードが書きやすく安心して保守することができた 成長できたという実感があった 難しかったこと、学び ドメイン知識は次第に流出していく 定期的なメンテナンスが大事 最後に おまけ エンジニア
本記事はドメイン駆動設計(DDD) Advent Calendar 2021 25日目の記事です。 「もっとビジネス変化に耐えられる設計を目指したい」「ただデータをやりとりするだけなのに複雑化してしまうのを防ぎたい」 様々な動機からドメイン駆動設計に入門しようとする方がいると思います。 自分もエンジニアとして働きはじめて、「どうしてすぐに変更しにくくなってしまうのか」「より柔軟な設計にするにはどうすればよいか」と悩むことが多くなり、良い設計手法を探って出会ったのがドメイン駆動設計でした。 最初はドメイン駆動設計関連の本ばかりを読んでいたのですが、途中から「これってドメイン駆動設計というよりはオブジェクト指向の話では?」とオブジェクト指向に興味を移し、さらに「より変化に強いプロダクト開発するにはチームから変化させないとまずいのでは?」とアジャイル開発に興味が移りました。 本記事では、ドメイン
こんにちは、イノベーションセンターの冨樫です。Network Analytics for Security プロジェクトに所属しています。 突然ですが皆さんはドメインパーキングというサービスを知っているでしょうか?詳細については後述しますが、以前イノベーションセンターの検証網でマルウェアに関する悪性通信が検知されたため通信先を調査したところ、ドメインパーキングだったことがあります。本記事ではこの調査を通して得られたドメインパーキングに関する知見とその調査過程を紹介します。また、今回紹介するドメインパーキングの悪用事例や外部インテリジェンスを活用した調査は基礎的な内容ですので、本記事は主に初学者の方の知見にしてもらうことを目的としています。 ドメインパーキングについて アラートの概要 Ursnif について 接続先についての調査 検知されたアラートの危険性について さいごに ドメインパーキン
2022年3月2日に確認した VALUE-DOMAIN でのサブドメインハイジャックが可能な脆弱性について経緯を説明します。 ついでに2016年の記事「VALUE-DOMAIN に存在していたアカウント乗っ取り可能な CSRF 脆弱性について」の続報も含めて、この記事で2022年現在の VALUE-DOMAIN の状況についてお伝えします。 脆弱性を2つ発見しました 第一:子ゾーン作成によるサブドメインハイジャック 第一の脆弱性の攻撃の原理 VALUE-DOMAIN のネームサーバについて 第一の脆弱性 発見後の経緯 サブドメインハイジャック攻撃を受けた場合の影響 第二:CSRF 攻撃によるドメインハイジャック ドメインハイジャック攻撃を受けた場合の影響 CSRF 攻撃によるドメインハイジャックの対策状況 VALUE-DOMAIN ユーザの方へ 脆弱性を2つ発見しました (第一)子ゾーン作
渡部篤 @watanabeatushi 市議2期、県議4期後、44回の総選挙に比例当選して衆議院議員になり、その後、大病して45回総選挙に落選して・・今は天下の素浪人。真正保守・ナショナリスト、日本浪曼派・京都学派の『近代の超克』・『世界史の哲学』 に惹かれ。経済ではデフレ脱却のための大胆な金融緩和・財政拡大支持。「現代貨幣理論」に共鳴、市場原理主義反対。 渡部篤 @watanabeatushi 「スパイ防止法」がないのは世界で日本だけ spyboshi.jp/spying/自衛権は国際法(国連憲章第51条)で認められた独立国の固有の権利で、国家機密や防衛機密を守り、他国の諜報活動を防ぐのは自衛権の行使として当然の行為。それで世界ではどの国もスパイ行為を取り締まる法整備をしている。 2018-10-10 01:07:53
ドメイン駆動設計をわかりやすく - ドメインのモデル設計を手を動かしながら学ぼう ドメイン駆動設計(DDD)が近年関心を集めていますが、同時にこの設計思想は難しい、わかりにくい、という見方もあります。さまざまなプロジェクトでドメイン駆動設計を実践してきたかとじゅんさんが、サンプル課題をもとに、ユースケース分析、モデル設計といった基礎を解説します。 はじめまして、Chatworkでテックリードをしている、かとじゅん( @j5ik2o )です。 僕は2010年ころより、大小さまざまなプロジェクトでドメイン駆動設計、いわゆるDDD(Domain Driven Design)を導入した開発を実践してきました。ドメイン駆動設計を主題としたワークショップなども主宰していますが、最近では加速度的にこの設計思想への関心が高まっていると感じます。本稿では、なにかと分かりにくいドメイン駆動設計の基本を、架空の
関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD(ドメイン駆動設計)に関心を持つ技術者にとってお手本になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。 どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。 これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させ
[注意喚起]ブラウザ互換ライブラリ「Polyfill.io」がドメイン名ごと中国企業に売却、CloudflareとFastlyが代替となる配信を開始 開発者がブラウザの互換性を気にすることなくWebアプリケーションを開発するためのJavaScriptライブラリ「Polyfill.io」が、ドメイン名ごと中国企業に売却されたことを受けて、CloudflareとFastlyが急きょライブラリをフォークし、安全が確認されているコードの配信を開始しました(Cloudflareの発表、Fastlyの発表)。 Polyfill.ioをドメインごと中国企業に売却 Polyfill.ioはAndrew Betts氏が開発したオープンソースのJavaScriptライブラリです。Polyfill.ioを組み込むことで、ブラウザのバージョンを気にすることなくWebアプリケーションの開発を行うことができる便利なラ
10. 設計スタイルの違い 2019/8/31 10 関心 モジュール構造 20:80 入出力 ドメインロジック ビジネスルールに基づく計算と判断のロジック画面、テーブル、Web API トランザクションスクリプト 画面やデータに注目して、入出力手続きを構造化 値の種類に注目して、独自の型を定義 ドメインオブジェクトモデル 11. 設計スタイルの違い 2019/8/31 11 関心 モジュール構造 20:80 入出力 ドメインロジック ビジネスルールに基づく計算と判断のロジック画面、テーブル、Web API トランザクションスクリプト ドメインロジックの設計と実装が アプリケーション全体の構造を左右する 画面やデータに注目して、入出力手続きを構造化 値の種類に注目して、独自の型でロジックを構造化 入出力の設計と実装が アプリケーション全体の構造を左右する ドメインオブジェクトモデル
リダイレクトの終了について投稿したゆやりん(@yuyarin)さんは「group.ntt/jp/ にすれば参照できる」と解決方法を紹介。しかし「リダイレクトしていないため、新しいURLでリンクされてないものはインデックス化されない。古いURLはエラーでインデックスから消されて、そのうち検索エンジンで探せなくなって存在しないのと同義になるので全くよくない」と問題点を訴えた。 なぜNTTはリダイレクトをやめたのか。同社に問い合わせたところ「12月までの旧URLへのアクセス数を見たところ、数がかなり減っていたため、影響はないと判断した。また、継続することでコストもそれに応じてかかっていくことも踏まえて、総合的な判断からリダイレクトの終了を決めた」と話した。 NTTは「新URLに変更したことをあらためて周知することで、ご迷惑をおかけしないように対応させていただきたい」と話したが、再びリダイレクトを
NTTドコモが2021年にサービスを終了したウォレットサービス「ドコモ口座」のドメイン「docomokouza.jp」が、GMOインターネットのドメイン登録サービス「お名前ドットコム」にて出品されていた件について、オークションが9月25日午後7時15分に終了した。132件の入札があり、最終的に402万円で落札された。 ドコモ口座は2020年9月に不正送金問題が発覚し、一部機能を「d払い」に移したあと21年8月にサービス終了を発表した。しかし、今も金融機関などにリンク先が残されていることが多く、金融サービスのドメインが第三者の手に渡ってしまうことで、本物と同じドメインを持つ、ドコモ口座を装ったフィッシングサイトが出てくる可能性があることから、X(Twitter)などを中心にそのリスクを危惧する声が相次いでいた。 落札者などの詳細は不明。現在ITmedia NEWS編集部では、NTTドコモにド
はじめまして、サイバーセキュリティ推進部の喜屋武です。 今回は2020年6月に発生したお名前.com上の当社アカウント乗っ取りによる「coincheck.com」のドメイン名ハイジャックのインシデントについて、発覚までの経緯とその後のインシデント対応についてご説明します。 1 発覚までの経緯 1.1 サービスの応答時間の遅延の確認 当社利用のドメイン登録サービス「お名前.com」で発生した事象について(最終報告) | コインチェック株式会社 でもタイムラインを記載しましたが、最初の異変は日頃からモニタリングしているサービスのレスポンスタイムが著しく遅延していたことでした。 当時のサービスのレスポンスタイム この異常を確認し、SRE チームが調査に乗り出しましたがこの段階では他に問題は確認されず、レスポンスが遅延している原因の特定には至っていませんでした。 1.2 他部署やユーザーからの問い
はじめに この記事はサービスを爆速で作ったり、ドメイン駆動設計の解説をするようなものではありません。 ドメイン駆動設計の勉強をしていて、手を動かす機会が足りないと感じていました。そこで、今の理解で実際に動くシステムをドメイン駆動で開発してみようと思いました。 本記事はその開発の過程や考えていたことを記録したものです。 「この人はこういう形に落とし込んだんだな~」くらいで見ていただけたらありがたいです。 作成するシステム 今回作るのはTODO管理システムです。 初回の開発では以下の機能を開発しました。 TODOのタイトルと詳細を登録できる 作成したTODOを検索できる 選択したTODOの詳細を確認、完了、削除ができる デモ デモなのでメールの確認はダミーです。新規登録をしたら画面に出るメール確認リンクを踏めば確認済みとなります。 その後右上のログインからログインしてください。 デモのデータベ
Internet Archiveからnote関連のキャッシュがまるごと消えてしまったそうだ(5ちゃんねるの書き込み)。新たな登録もできないという。noteの以前のドメインであるnote.muに関しても完全にブロックされているとのこと。 5ちゃんねるのInternet Archive総合スレの書き込みによると、8月上旬まではnote.comドメインのキャッシュが共有されていたという。8月に発生したnoteのIPアドレス流出事故の後に対処されたのではないかとしている。実際にnote.comのrobots.txtを見るとInternet Archiveとウェブ魚拓のクロールを拒否する記述がされている。 あるAnonymous Coward 曰く、
本書は、初めてDDDを学ぶ方、もしくは実際に着手して「難しい!!」と感じているエンジニアの方を対象とした、ドメイン駆動設計(以下、DDD)についての解説書です。 近年、ソフトウェアのレガシー化が社会的に問題になっていると言われています。 DDDはレガシー化への対策として非常に有用なものですが、日本語で出ている書籍「エリック・エヴァンスのドメイン駆動設計」や「実践ドメイン駆動設計」は非常に重厚かつ難解で、初学者が実用に到達するまでには長い時間と試行錯誤が必要なのが実情です。 そこで本書では、迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、 具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。 また、その後にはレイヤーごとの個別のトピックについて、1章ずつ詳しく解説します。 ■本書の構成 本書は以下の構成になっています。 「第1章 DD
この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事
これは何 証券Fintechに入るぞ・入ったぞ!という人がドメインについて学べるような本・ページを集めてみました。 会社特有の業務知識ではなく業界で広く使える知識を学べる物を集めようとしていますが、筆者の守備範囲依存による分野の偏りは否めません。(追記: たとえばデリバティブ関連などは筆者の経験がないのでほぼ記載がありません。) こういう分野があってこういうことが議論されてるんだなーといった形で興味を持つきっかけとしての本を挙げています。(自分で金融商品を考えるぞ!という人向けではなく、ETF扱うサービスの開発するならETFって何かくらいはうっすら知っておきたいよねーくらいのモチベーションの人向き) 最初に何読めばいい? せっかくだからなにか勉強したいなーという人は資格系の欄にある証券外務員についての本を買っておくと広めに勉強できます。 ただし、個別の金融商品(ETF, 投資信託,…)の解
株式会社ログラスの松岡です。 本記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、本記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p
本日(1月18日)発売された、Software Design誌 2023年2月号の第一特集で「ドメイン駆動設計入門」を書きました。 執筆の意図と記事の概要を簡単にまとめておきます。 Software Design 2023年2月号|技術評論社 執筆の意図 特集のサブタイトルにある通り「設計力を磨きたい」読者が、ドメイン駆動設計の基礎を知ることで「設計の手法とアイデアの引き出し」を増やすことの役に立てればと思い執筆を引き受けました。 重視したこと 断片的な用語やパターンの解説でなく、ドメイン駆動設計の全体像と要点を伝える 全体像を伝えるための図や表を多めにした(ソースコードの例は少ない) 全体像と要点は、原典である『エリック・エヴァンスのドメイン駆動設計』(以下『ドメイン駆動設計』)の説明を中心にした ドメイン駆動設計の具体例として『ドメイン駆動設計』に出てくる国際海上貨物輸送の具体的な業務
株式会社ログラスの松岡(@little_hand_s)です。 最近、値オブジェクトに関して書かれているブログ記事を見ますが、 SNSなどにおいてDDDにおける値オブジェクトについて誤解されているような反応が見受けられました。 そこで、この記事では「DDDにおける値オブジェクトの位置付け」について解説し、具体的なモデル・コードを用いながら誤解を解いていきたいと思います。 なお、値オブジェクトに関する詳細な説明はここでは行いませんのでご了承下さい。 DDDの目的 まず最初に、DDDの目的について確認します。 DDDの目的は、モデリングを通じてソフトウェアの価値を大きくすることです。 これに関しては、こちらの記事で詳細に解説しているのでこちらをご覧ください。 ドメイン駆動設計は何を解決しようとしているのか - little hands' lab ここで大切なのは、モデルは一回のモデリングで完成形
by Sean Davis 「XYZ」はアルファベットの最後の3文字で、3次元空間や色空間の座標の表現にも使われている印象的な文字列です。また、Googleの親会社であるAlphabetの公式サイトである「https://abc.xyz/」に使用されていることから、新しく立ち上げるサイトのドメインにぴったりなように思えます。ところが、実際に.xyzをサイトのURLに使ってひどい目に遭ってしまったという会社のCEOが、その「.xyzドメインは危険」とする体験談を語りました。 The Perils of an .xyz Domain https://www.spotvirtual.com/blog/the-perils-of-an-xyz-domain/ ゴードン・ヘンプトン氏がCEOを務めるSpotは、リモートワークをする企業向けにバーチャルな3Dコワーキングスペースを提供するサービスを展開
株式会社ログラスの松岡(@little_hand_s)です。 ドメイン層のオブジェクトを設計する際に、重要な基本方針があります。 ドメインモデルの知識を対応するオブジェクトに書く 常に正しいインスタンスしか存在させない この2つを守ると、非常に保守性の高いコードにすることができます。 以下、詳細に解説します。 ドメインモデルの知識を対応するオブジェクトに書く ドメイン知識(ルール/制約)を表現する実装を、ドメイン層のオブジェクトに寄せていきます。 この判断は、「ドメインモデル図に書かれた吹き出しの内容が、どの層で実装されているか」という基準に基づき行います。 この基準はコード設計の指針として非常に役立ちます。 設計の良し悪しというのはさまざまな基準があるため、レビューをしていてもいわゆる「俺の考えた最強の設計」同士が戦ってしまうことがあります。 しかし、「ドメイン知識はドメイン層に書く」と
はじめに こんにちは。 バックエンドエンジニアの松本です。今回は、会計システムの開発を通じて、 CADDi におけるプロダクト開発の様子を紹介します。 2024年3月現在、CADDiでは2つのサービスを提供しています。1つは図面データ活用クラウド「CADDi Drawer」で、もう1つは加工品製造サービス「CADDi Manufacturing」です。 今回、後者の加工品製造サービス「CADDi Manufacturing」向けに、 会計システムを構築しました。これは、生産管理システムや拠点管理システムから取得した各種情報を基にして、会計仕訳データを生成し、経理部門に公開する役割を持ちます。 はじめに 会計システムのアーキテクチャとその狙い 計算処理を少しずつ進める 会計数値の妥当性をダッシュボードに表示する 会計システムのモデリングと最初の開発 仕訳の流れを整理して、ドメインモデル、デー
ドコモは現在、各サービスのドメインを「docomo.ne.jp」へ統合する作業を進めており、現在使用しているもの、すでに使用をやめたものを含め同社の専門部署で一括管理しているという。そのうえで「docomokouza.jp」については、社内管理の不手際により、一時的にドコモの保有ではなくなっていたとしている。 今回の「docomokouza.jp」はドコモが取り戻したため不正利用される心配はなくなったが、こうしたドコモ保有のドメインを失った場合はどういった対応を取るのだろうか。同社は「弊社の商号、商標を含むドメインが第三者に取得されて不正に利用された場合は、JP-DRP(JPドメイン名紛争処理方針)という公的な指針によって必要な措置をすみやかに取る」としている。 JP-DRPは、ドメインにまつわる商標権者とドメイン登録者の紛争処理に関する規約を定めたもの。ドメイン名の不正登録・使用を回避す
Intro IETF の RFC は、いくつかの場所で同じものが公開されている。 どの URL が最適なのか、という話。 結論は www.rfc-editor.org だ。 RFC Hosting Site 例えば RFC 9110 - HTTP Semantics で言うと、以下の 4 つがある。 https://tools.ietf.org/html/rfc9110 https://datatracker.ietf.org/doc/html/rfc9110 https://www.rfc-editor.org/rfc/rfc9110.html https://httpwg.org/specs/rfc9110.html まずは、これらの違いを簡単に解説する。 tools.ietf.org IETF がホストする RFC は、 tools.ietf.org だった。 RFC 2616: H
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 13日目の記事です。 はじめに 〇〇を削除できるかどうかのビジネス処理、皆さんはどう実装していますか? 同僚の話題になった記事でも削除の認可処理をどこに記述すべきか?は難しいと説明されています。今回はお題は認可っぽいもので書きますが広範に「削除ができるかどうか?」のビジネスロジックをドメイン層にどう閉じ込めるかの便利な実装パターンを紹介します。 削除処理のビジネスロジックの取り扱いは難しい 削除処理のビジネスロジックの実装はシンプルだけど更新処理や作成処理と比べて意外と難しいです。 それはなぜかというとドメインオブジェクト内の実装に削除処理を書くことができないからです。 例えば権限に管理者と一般ユーザーの二つの権限があるとします。
2021/12/20追記 指摘されて気づいてしまいましたが、間違ってますね... 以前スライドを書いた時に全然気づいていませんでした 反省のために消さずに、取り消して残しておきます 「年齢計算ニ関スル法律」という法律がある。 明治三十五年法律第五十号(年齢計算ニ関スル法律) | e-Gov法令検索 とても短い法律で条文は3つしかない。 ① 年齢ハ出生ノ日ヨリ之ヲ起算ス ② 民法第百四十三条ノ規定ハ年齢ノ計算ニ之ヲ準用ス ③ 明治六年第三十六号布告ハ之ヲ廃止ス ポイントは①で、生まれた日から起算するので法律上は1年が経過した時に1つ歳を取ることになる。つまり、誕生日の前の日の24時に年齢が加算されるので、日単位でみると誕生日の前の日にもう年齢は進んでいる、ということになる。 同じ年の4月2日生まれの人と、4月1日生まれの人とでは小学校に入学する年度が違う、というのはよく聞く話だと思う。 この
コロナ禍で行われた「Go Toイート」事業では、農林水産省から委託を受けた民間の会社や商工会議所などが「ドメイン」と呼ばれるインターネット上の住所を新たに取得するなどして、都道府県ごとにウェブサイトが設けられました。 ところが、「Go Toイート」の終了に伴ってウェブサイトが閉鎖されたことから、ドメインが手放されるようになっていて、ドメインの登録サービス会社のオークションを通じて落札されるなどして、同じURLで別のサイトが表示されるケースがあることがわかりました。 NHKが調べたところ、少なくとも15のドメインにこれまでと異なるサイトが開設されていて、中には、オンラインカジノの情報サイトや「パパ活」に関するサイトなどが開設されているケースもありました。 こうしたドメインの扱いについて、政府のガイドラインでは「正規のウェブサイトになりすました不正なウェブサイトに誘導されないよう、対策を講じた
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く