タグ

設計に関するlouis8917のブックマーク (11)

  • 「MVCの勘違い」について、もう一度考えてみる - 圧倒亭グランパのブログ

    お久しぶりです。@at_grandpa です。 今回、Model View Controller について再考する機会があったので、自分なりに整理してみました。 勘違い MVCの勘違いに関しては、以下のSlideShareが有名かと思います。 やはりお前らのMVCは間違っている @mugeso これにはドキッとしたことを覚えています。 このスライドで「間違っている!」と指摘されている形式を、そういうものだと理解していたからです。 上記で指摘されている勘違い形式を、自分なりにわかりやすく噛み砕き、図にしてみました。 Userからの入力をControllerが受け取る Controllerはデータ置き場であるModelからデータを取得する 取得したデータをControllerが加工する 加工したデータをViewに転送する Viewは、受け取ったデータを視覚表現しディスプレイに表示する 自分の中

    「MVCの勘違い」について、もう一度考えてみる - 圧倒亭グランパのブログ
  • 第3回 詳細設計工程のITアーキテクト

    ITアーキテクトが作成する成果物に注目し、何のために作るのかを明らかにします。システム開発のライフサイクルを軸にし、今回は詳細設計工程を対象にします。詳細設計工程では、主に次の5つの成果物を作成します。 (1)機能パッケージをまたがる状態遷移図 (2)排他制御(ロック)仕様書 (3)コンポーネント図 (4)インピーダンスミスマッチの解決手順書 (5)物理データモデル図 この工程のポイントは「変化への対応」です。システムへの要求仕様は決して確定しません。開発途中も初期リリース後も変化し続けます。この「変化」にどう対応するのか、これが情報システムの「質的な複雑さ」の正体です。検証しやすさを最大化し、変化対応時の影響範囲を局所化するように、モジュール分割の基準を決定します。 ITアーキテクトは、要求仕様の全体整合性に責任を持ちます。準正常系や異常系の仕様など、これまで明文化されなかった「暗黙の

    第3回 詳細設計工程のITアーキテクト
  • 第2回 基本設計工程のITアーキテクト

    ITアーキテクトが作成する成果物に注目し、何のために作るのかを明らかにします。システム開発のライフサイクルを軸にし、今回は基設計工程を対象にします。基設計工程では、主に次の5つの成果物を作成します。 (1)論理データモデル図 (2)パッケージ図(永続化視点) (3)パッケージ図(機能視点) (4)アーキテクチャー設計ドキュメント (5)アーキテクチャー評価ドキュメント ITアーキテクトのはこの工程で、アプリケーションの構造を創出し、その構造を評価します。基設計工程ではサブシステムごとに設計作業を進め、要件定義の深堀や、要件の変更(改善)が発生しているはずです。そこでITアーキテクトのタスクとしてポイントになるのは、並行する設計作業間で矛盾が生じないようにサブシステム間の依存関係を整理し、また、そのアプリケーション構造を支えるインフラを含めてアーキテクチャーを設計することです。 IT

    第2回 基本設計工程のITアーキテクト
  • 第1回 要件定義工程のITアーキテクト

    ITアーキテクトが作成する成果物に注目し、何のために作るのかを明らかにします。システム開発のライフサイクルを軸にし、今回は要件定義工程を対象にします。要件定義工程では、主に次の5つの成果物を作成します。 (1)Vision Document (2)利害関係者マップ (3)概念機能モデル図・概念データモデル図 (4)非機能要件定義書/品質特性シナリオ (5)グランドデザイン ポイントは「ビジネス視点」と「システム視点」の両方を持つこと。技術者は総じて「How(どのようにつくるか)」への思考(=システム視点)が先行しがちです。これでは「間違ったものを正しくつくる」ことになってしまいます。それを避けるには、「Why(なぜつくるのか)」と「What(なにをつくるのか)」を明らかにすること、つまり、ビジネス視点を持つことです。 ITアーキテクトは、アーキテクチャー設計に対する「説明責任」が伴います。

    第1回 要件定義工程のITアーキテクト
  • 第47回 SEA関西プロセス分科会「ドメイン駆動設計」#SEAKANSAI #kspinddd #dddjp

    第47回 SEA関西プロセス分科会「ドメイン駆動設計」に関するつぶやきをまとめました。 http://sea.jp/kansai/wp/?p=71 第47回 SEA関西プロセス分科会 続きを読む

    第47回 SEA関西プロセス分科会「ドメイン駆動設計」#SEAKANSAI #kspinddd #dddjp
  • ドメイン駆動設計 実践ガイド

    始めよう! ドメイン駆動設計&マイクロサービス開発 ~C# と Azure Service Fabric で最高の DDD 開発を~貴志 上坂

    ドメイン駆動設計 実践ガイド
  • 先日倒産したメモリメーカーの友人と飲んできた話

    彼は純粋な技術屋といった感じで、 愚痴もまじっていたせいだろうか、何を言ってるかわからない部分もあったが、 いろいろと興味深い話を聞くことができた。 「結局、装置があれば韓国でも中国でもどこでも作れるようになって、値段のたたきあいになっちゃたんだろ」 という私に対して、彼は言った。 「体力勝負で負けたのは否定しない。だけどな、装置があれば誰でも作れるというのは大間違い」 「最大の要因は、やつらの技術力が高かったことだと思う。というかうちの規模の会社が研究開発で対抗できてたのがある意味奇跡。」 メモリは『装置があれば作れる汎用品』なわけではない。ということを彼は熱弁していた。 回路ひとつをとってみても、『アナログ』技術の塊で、 記憶素子のわずかな物理量(数10フェムトとか言ってた)の変化を 増幅する高精度なアンプだとか、 秒速数ギガビットの信号を処理するためにピコ秒単位で 信号のタイミングを

    先日倒産したメモリメーカーの友人と飲んできた話
  • dankogaiさんへの返信 : 小野和俊のブログ

    昨日、「メンテナビリティの高いソースコードを目指して」というエントリを書いたところ、dankogaiさんから、「コードも見せていないお前にコードを語る資格はない」と怒られてしまったので返信エントリ。 実はブログを初めて1,2年くらいの頃はコードを含むエントリをそこそこ書いてたのですが、プログラマーでない知人から「何の話か全然わからなかった」と言われ、またdankogaiさんも指摘している通り、「コードについて書く方がコードを書くより読まれる現実」があり、コードを含むエントリはJava Programming Tipsという別のブログに移した経緯があります。 ではどこに力を入れているかというと、私が一番力を入れいてるのはDataSpiderという商用ソフトウェアの設計と実装ですが、これはアプレッソの50人の社員を10年間支えてきてくれているソフトウェアなので「はい、どうぞ」とソースコードをお

    dankogaiさんへの返信 : 小野和俊のブログ
  • webデザインにおける視線誘導のおはなし | 07design.blog

    こんにちは。今回はレイアウトの記事を書きます。「グーテンベルク・ダイヤグラム」という言葉をご存じでしょうか。 なんだかすごく中二心をくすぐられる言葉ですね。「グーテンベルク・ダイヤグラム」とは均等に配置された同質の情報を見る際の、・・・こんにちは。今回はレイアウトの記事を書きます。 「グーテンベルク・ダイヤグラム」という言葉をご存じでしょうか。 なんだかすごく中二心をくすぐられる言葉ですね。 「グーテンベルク・ダイヤグラム」とは均等に配置された同質の情報を見る際の、一般的な視線の流れのパターンを表した図式のことです。 簡単に言うと「人間の目は左上から右下方向へ、チラチラしながら遷移する」というものです。 こういった視線の流れのパターンは、エディトリアルデザインなどでは当たり前に使われている技法・考え方らしいです。 テキストをレイアウトする場合には、左上・右下に重要なコンテンツを配置す

  • 第1回 「失敗学」とは? | gihyo.jp

    ここに挙げた各要因ごとに失敗経験を挙げだしたなら、誰もが枚挙に暇がないのではないでしょうか? 失敗学の提唱者である畑村洋太郎氏が「千三つ」(⁠成功するのは1,000回のうち3回)という言葉を度々使用しているように、失敗学では「失敗はありふれたもの」というのが大前提となっていますから、無闇に失敗を恥じることはありません。 とくに、新たな知見をもたらしてくれることから、「⁠未知」に起因する失敗は良い失敗とみなされています。 また、個人レベルで見れば「無知」も一種の「未知」ですから、「⁠よい失敗」にこそ分類されていませんが、「⁠無知」による失敗よりも、それを恐れて挑戦をしないことに対して注意を喚起しています。 つまり失敗学では、失敗は「忌避」するものではなく、その先の成功のために「利用」するものなのです。 ただし注意して欲しいのは、失敗学における「良い失敗」「⁠失敗はありふれている」という考え方

    第1回 「失敗学」とは? | gihyo.jp
  • Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;

    【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって? データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した

  • 1