技術的な抽象性のレイヤについて - Kentaro Kuribayashi's blog
ネットワークにおけるOSI参照モデルや、アプリケーション実行環境におけるハードウェア→OS→ミドルウェア→アプリケーション→UI(ブラウザ・モバイル)というレイヤ(こういうのに名前あるのかな。「フルスタックエンジニア」という言葉があることからして「技術スタック」とでもいうのだろうか)のように、ある技術的まとまりを、フラットにではなく階層をなすものとして考える習慣が存在する。それぞれのレイヤの独立性・簡潔性を担保するためだ。 今日、いろんなひとと話をしていて、こういう風にも考えられるよなと思ったことがあったので、以下にメモしておく。 それぞれについての贅言は必要なかろう(念のため、「デザイン」はいわゆる設計のこと)。また、抽象度が高低に、なにかしら技術的な優劣があるというわけでももちろんない。単に、階層を成しているものとして捉えると整理がつくだろうというだけのこと。ただし、上述の例とは異なり
マイクロサービスアーキテクチャ�とは何か
Dapr × Kubernetes ではじめるポータブルなマイクロサービス（CloudNative Days Tokyo 2020講演資料）
Cre8ive Thought
CQRS à la Greg Young I have had the pleasure of spending a 2 day course and many geek beers with Greg Young talking about Domain-Driven Design specifically focussed on the Command and Query Responsibility Segregation (CQRS) pattern. Greg has taken Domain-Driven Design from how Eric Evans describes it in his book and has adapted mostly the technical implementation of it. Command Query Separation (C
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
ITの地殻変動はどこに起きているのか～ソフトウェアの複雑さをどのようにして手なづけるか？ - プログラマの思索
ソフトウェアの本質的な問題とは何だろうか？ 僕は、「ソフトウェアの複雑さをどのようにして手なづけるか？」という問題だと思う。 以下、ラフなメモ書き。 【1】問題提起 ソフトウェアをインタプリタのように、書いては動かし、というやり方で作っていく時は楽しい。 しかし、じきに、行数が大きくなり、ソースファイルを分割して、クラス設計していくうちに、どんどんソフトウェアは肥大化し、複雑になっていく。 大人数で開発し始めると、当初の設計思想や開発の規律からズレ始める。 ソフトウェアの複雑さをどのように手なづけて、制御していくべきか？ その問題を幾つかの観点から考えてみる。 【2】単純な解決法～間接層を設ける 一つの塊で実装するのではなく、分割する。 その時に、間に「間接層」を入れる。 例えば、DAO、サービス層かな。 ダイクストラの下記の言葉を思い出す。 another level of indire
要求の複雑性とアーキテクチャの複雑性 - assertInstanceOf('Engineer', $a_suenami)
なんか朝ふと考えたこと特にまとまってない状態で書いてみる。もしかしたら今年最後のエントリになるかもしれないエントリがそれでいいのかっていう気がしなくもないけど。 僕たちのようにソフトウェアをつくている人たちは本質的に複雑性に立ち向かうことが主な営みである。世の中というのは複雑であり、その複雑な世の中で問題とされていることを解決しようとするとその中でもとりわけ複雑な領域を取り扱わなければならない。そうでなければそもそもソフトウェアなど必要ないことになる。人間がそれをやるにはワーキングメモリが少なすぎるとか、時間がかかりすぎるとか、原因は何かわからないけど何らかの理由によりちゃんと遂行できないものこそソフトウェアをつくって解決するべきなのだということになる。 逆に言えば僕たちソフトウェア産業従事者が今も仕事を手に出来ていてちゃんとご飯が食べられているのは世の中が複雑であることの恩恵かもしれない
[セッションレポート]NetflixにおけるMicroservicesアーキテクチャ #reinvent | DevelopersIO
この記事は AWS re:Invent 2014、PFC304-JT - Effective Interprocess Communications in the Cloud: The Pros and Cons of Micro Services Architectures - Japanese Trackのレポートです。 スピーカーはNetflixのSudhir Tonse。 レポート どうやってMicroservicesに変化していったのかを話したい。 これまで何度か本番環境が停止し、そこからたくさんのことを学んだ。それを共有したい。 Netflixについて。映画のストリーミングサービス。 PCやPS4などで再生できる。 ネットワークの1/3のトラフィックをNetflixが占めることがある。 20億以上のエッヂAPIリクエストがあって、500以上のMicroservicesが動いてい
![[セッションレポート]NetflixにおけるMicroservicesアーキテクチャ #reinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/9f822a733dd20e28505900c2cfb90a863cdb365a/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F11%2Fre_invent_eyecatch.png)
第12回 CQRS
クラウドを本格活用する時代に入り、エンタープライズアプリケーションのアーキテクチャーに変革が起きている。その一つが、スケーラブルなシステムを実現する「CQRS」（Command Query Responsibility Segregation）アーキテクチャーだ。オブジェクト指向の大家Bertrand Meyer氏やGreg Young氏によって提唱された。 一言でいうと「書き込み（Command）と読み出し（Query）の責務を分離する設計モデル」で、データ書き込みシステムとデータ読み出しシステムを別々に用意することになる。 CQRSアーキテクチャーを採用した場合、システムがデータ更新要求を受けると、その要求に応答してからデータを更新し、キューイングなどの仕組みを用いて読み出しシステムに非同期でデータを反映する。更新データを参照するには、別途読み出しシステムにアクセスする必要がある。 デ
ブラック企業から学ぶMVCモデル
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発慎一 古賀
Monolithic Architecture is Dead
社内 TeckTalk 資料 - Microservices の紹介
マイクロサービス（microservices）とは何か – recompile.net
マイクロサービス（microservices）という言葉をご存知でしょうか？ 今、エンタープライズ界隈のソフトウェアエンジニアの間でマイクロサービスという言葉がにわかに盛り上がりつつあります。 マイクロサービスはJames Lewis氏によって提案された言葉です。詳細については、彼がMartin Fowler氏と共著で書いた「Microservices」という記事を参照してほしいのですが、ようするにひとつのアプリケーションを、Railsのような一枚岩のアーキテクチャではなく、複数の軽量なサービスを連携させたアーキテクチャでつくろうというアプローチです。 上述の記事 では、マイクロサービスの特徴が九つほど上げられています。 サービスによるコンポーネント化：ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。 ビジネスケイパビリティに基づく組
The Architecture of Open Source Applications (Volume 1)The Hadoop Distributed File System
The Architecture of Open Source Applications (Volume 1) The Hadoop Distributed File System Robert Chansler, Hairong Kuang, Sanjay Radia, Konstantin Shvachko, and Suresh Srinivas The Hadoop Distributed File System (HDFS) is designed to store very large data sets reliably, and to stream those data sets at high bandwidth to user applications. In a large cluster, thousands of servers both host directl
HugeDomains.com
Captcha security check 42qu.com is for sale Please prove you're not a robot View Price Processing
- 不吉な匂い
不吉な匂いとは、リファクタリングを必要とするコードから感じられる雰囲気を、比喩で表したものです。 ここでは、感じ取った不吉な匂いに対して、どのような解決法を選ぶことができるかを取り上げます。 匂いとして示されているのは、次の２２のケースです。ひとつずつ見ていきましょう。 また、解決法に添えられている数字は、参考書籍「リファクタリング」の何ページに記されているかを示しています。
開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 - 達人プログラマーを目指して
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に（アーキテクトではなく）プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GiltでのScala，Docker，AWSを使ったマイクロサービスのスケールアップ
NSQ-Centric Architecture (GoCon Autumn 2014)
CQRS
システムアーキテクト
The Architecture of Open Source Applications 日本語訳