タグ

アーキテクチャに関するsunset01のブックマーク (3)

  • なぜDDD初心者はググり出してすぐに心がくじけてしまうのか - little hands' lab

    背景 直近のプロジェクトでDDDの思想に則ったアーキテクチャで一つリリースまで漕ぎ付けまして、そこに至るまで色々と調べたり試行錯誤をしながら学んだことを書いていこうと思います。 一番にですね、大体のDDDに興味を持った人がいうのが 「単語が難しいばかりで結局イメージが湧かない」 「ドメイン駆動のを読もうとして速攻で心が折れた」 ということなんですよね。 DDDは思想としてすごく面白く、とても実用性なものなのに、なんでこんなにわかりづらいのか、ハードルが高いのか!! という点について、私なりの解釈を述べたいと思います。 心をくじく要因 Eric Evansは説明が圧倒的に下手。笑 ドメイン駆動設計といえば原著がこの(以下、原典)なのですが、 エリック・エヴァンスのドメイン駆動設計 この当〜〜〜にわかりづらいです。重要なことは確かに書いてあるんですが、構成がかなりしんどくてまとまり

    なぜDDD初心者はググり出してすぐに心がくじけてしまうのか - little hands' lab
  • 書籍「Clean Architecture」が最高すぎたのでエッセンスをまとめてみた

    記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。 第1部 イントロダクション ソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。 ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。 「あとでクリーンにすればいいよ。先に市場に出さなければ!」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。 すべてのソフトウェアシステムは、2

    書籍「Clean Architecture」が最高すぎたのでエッセンスをまとめてみた
  • アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD

    注釈: CASH LAYER:キャッシュレイヤ FRONT END:フロントエンド ASSET SERVE:アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER:ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD:クラウド ALL READS! :全ての読み込み WRITES:書く READS:読む MASTER:マスタ INPORTANT POINTY THINGS:重要な鋭い情報 MULTI MASTER DB CLUSTER:複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー

    アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD
    sunset01
    sunset01 2016/01/15
    ここで言ってるのは狭義のアーキテクチャと思う。広義のアーキテクチャは、ユーザ(ステークホルダ)のユースケースを収集・集約し、外部I/F、機能(論理)設計に入る。いきなりSWやDBなどの物理設計には入らない。
  • 1