デンソーに身代金要求型のサイバー攻撃か 犯罪グループが声明 | NHK
身代金要求型のコンピューターウイルスによるサイバー攻撃を行う犯罪グループが、トヨタグループの大手自動車部品メーカー「デンソー」の機密情報を盗み、公開すると、ネット上の闇サイトに声明を出したことがわかりました。 デンソーは「ドイツにある拠点でネットワークへの不正アクセスを確認し、調査している」としています。 情報セキュリティー会社の「三井物産セキュアディレクション」によりますと、日本時間の13日午後、「Pandora」と名乗るサイバー犯罪グループが、ダークウェブ＝インターネット上の闇サイトに、愛知県に本社のあるトヨタグループの大手自動車部品メーカー、デンソーの機密情報を盗みとり、公開すると声明を出したことがわかりました。 それによりますと、発注書やメール、図面など、15万7000件以上、1.4テラバイトのデータがあるとしています。 「Pandora」は、身代金要求型のコンピューターウイルス、
ドメイン駆動 + オニオンアーキテクチャ概略[DDD] - little hands' lab
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほど」となって「あれ、結局ヘキサゴナルじゃん」と
![ドメイン駆動 + オニオンアーキテクチャ概略[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/08f5c6031dd21f86d259a1d9e9f6383a3180a1cb/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171011%2F20171011062558.png)
レイヤードアーキテクチャの視点 - Qiita
「ValueObjectという考え方」でDDDの片鱗について書かせていただきました 今回はDDD本のなかでも少し抽象度の高い「レイヤードアーキテクチャ」について深堀っていきます レイヤードアーキテクチャとは レイヤーアーキテクチャ・レイヤードアーキテクチャと呼ばれているこのアーキテクチャ指向です DDDは特定技術へ依存しているわけではないのでDDD=レイヤードアーキテクチャ！とならないように気をつけましょう 上位互換の思想として以下のものがあります ヘキサゴナルアーキテクチャ オニオンアーキテクチャ クリーンアーキテクチャ 基本的にどのアーキテクチャも一貫して責務を適切に設定して依存関係を明確にするという目的があります 一番原始的（？）なレイヤードアーキテクチャはその名の通り 責務を適切に設定した塊＝層（レイヤー）をイメージします これだけじゃなんのことやらって感じですね 更に技術っぽい責
やっと「依存性の逆転(Dependency Inversion)」がわかった - Qiita
依存性逆転の原則 - Wikipedia オブジェクト指向設計において、依存性逆転の原則、または依存関係逆転の原則[1]（dependency inversion principle) とはソフトウエアモジュールを疎結合に保つための特定の形式を指す用語。この原則に従うとソフトウェアの振る舞いを定義する上位レベルのモジュールから下位レベルモジュールへの従来の依存関係は逆転し、結果として下位レベルモジュールの実装の詳細から上位レベルモジュールを独立に保つことができるようになる。この原則で述べられていることは以下の２つである:[2] A. 上位レベルのモジュールは下位レベルのモジュールに依存すべきではない。両方とも抽象（abstractions)に依存すべきである。 B. 抽象は詳細に依存してはならない。詳細が抽象に依存すべきである。 正直こういうのを見てもいまいちわかってなかった。 しかし、よ
「依存性逆転の原則」の自分なりの解釈 - 圧倒亭グランパのブログ
「依存性逆転の原則（DIP：Dependency Inversion Principle）」に関して考える機会があり、自分なりに言語化できそうなのでまとめます。ご指摘は大歓迎です。 目次 目次 TL;DR 考えるきっかけ 具体例から紐解いていく べた書きのモジュールA モジュール分割による依存性の出現 モジュールの安定性 安定依存の原則 （SDP: Stable Dependencies Principle） 間違った「依存方向の逆転」 DIPに基づいた「依存方向の逆転」 まとめ TL;DR より安定したモジュールの方向へ依存するよう設計し、ソフトウェアの安定性を高めることが重要 不安定なモジュールが 依存されている と修正範囲が大きくなるため、 依存されない ようにしたい。そのために、依存方向を逆転させたい DIPは「モジュールへの依存方向は逆転可能」ということを示し、「その方法」を解説
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
