七つの設計原理概要障害を作り込まないために考慮すべきプログラム構造上の七つのポイントである。実際に検出された障害の一件一件について、どうしたら開発時に障害を作り込まないようにできたかという観点から根本原因を分析した結果、導かれた原理である。一覧単純原理 自然であれという原理同型原理 形にこだわるという原理対称原理 形の対称性にこだわるという原理階層原理 形の階層的美しさにこだわるという原理透明原理 透明性こだわるという原理明証原理 ロジックの明証性にこだわるという原理安全原理 必然性を意識するという原理 参考ソフトウェア品質知識体系ガイド―SQuBOK Guide作者: SQuBOK策定部会出版社/メーカー: オーム社発売日: 2007/12メディア: 単行本Amazon.co.jpで詳細を見る3.4.29Ｔ：七つの設計原理【富士通】 日野克重，ソフトウエア障害の分析と予防，第４回ＳＰＣシ
目次 プラトン的モデル 言うべきことを言う コンテキスト 価値提案を把握する 単一責任システム エンティティは ID とライフサイクルを持つ 値オブジェクトは記述する 集計ルートによりエンティティを結合する ドメイン サービス モデルの主要な操作 リポジトリにより集計ルートを省略する データベースの関連事項 DDD の使用を開始する ドメイン駆動設計 (DDD) とは、洗練されたオブジェクト システムの設計に役立つ原則とパターンをまとめたものです。設計に DDD を適切に適用することで、ドメイン モデルと呼ばれるソフトウェア抽象化を実現できます。このモデルにより複雑なビジネス ロジックをカプセル化できるため、実際の業務とコードとの間に存在するギャップを小さくすることができます。 この記事では、DDD に関連する基本的な概念と設計パターンについて解説します。機能豊富なドメイン モデルを設計し
アーキテクチャ・ジャーナル コンポジット アプリケーション ― 新しいパラダイム Chris Keyser 2009/02/16 本コーナーは、マイクロソフトが季刊で発行する無料の技術論文誌『アーキテクチャジャーナル』の中から主要な記事を Insider.NET 編集部が選び、マイクロソフトの許可を得て転載したものです。基本的に元の文章をそのまま転載していますが、レイアウト上の理由などで文章の記述を変更している部分（例：「上の図」など）や、図の位置などを本サイトのデザインに合わせている部分が若干ありますので、ご了承ください。『アーキテクチャ ジャーナル』の詳細は「目次情報ページ」もしくはマイクロソフトのサイトをご覧ください。 ■概要 コンポジット アプリケーションは、権限を与えられた技術的なビジネス ユーザーが、コンポーネント化されたビジネス機能を相互接続できる、長い間求められてきたビジネ
最後に，設計/アーキテクチャの不具合で火を噴いたプロジェクトの火消し術を取り上げよう。この場合の主な対処法は，（1）原因を特定して技術的な対策を打つ，（2）設計書をレビューする，（3）運用でカバーする，の三つである。 システム開発プロジェクトのコンサルティングを手がけるフィッシュボーン研究所の大坪保行氏（代表取締役社長）は，テスト・フェーズで当初見込んでいた処理性能が出ないことが露見したEDIシステムの開発プロジェクトを支援したことがある。 そのシステムは，あるWebアプリケーション・サーバーを使って開発していたが，システムの総合テスト・フェーズで，トランザクション処理性能が全く出なかった。詳しく調べてみると，システムが受け付けたすべての処理を，Webアプリケーション・サーバーが待ち行列（キュー）で管理していることが分かった。 本来ならWebアプリケーション・サーバーの特性をつかんで，キュ
id:n-ichimuraさん、S2Laszloの開発は止まっているようですが、別の方に引き継いでも良いですか。よろしくお願いします。 http://d.hatena.ne.jp/higayasuo/20050825#1124957707で書いたActionとServiceの統合ですが、いろいろ考えてみましたがActionの責務が多いと思うので、やはりActionとServiceは分離すべきだと思います。 そもそもこの話は、Dxoをどこに置くべきかの話だったのですが、やはりServiceにおくべきだと思います。 モデルは、その使われる場所によって、プレゼンテーションモデル、ドメインモデル、ERモデル(RDBMSの場合)に分かれます。プレゼンテーションモデルはプレゼンテーション層で使われ、ドメインモデルはビジネスロジック層で使われ、ERモデルはリソース層で主に使われることになります。 どのモ
んー、マーケットどころか社員からも受け入れられてないなんて・・・・・ http://www.infoq.com/jp/news/2008/05/sun-deflextions-continue 業務システムにOOはほとんど必要ないと考えている断然トランザクションスクリプト派の わたしですがｗ、下記の説明をみても従来のトランザクションスクリプトとの違いがそんなにない気がする。 DDDのServiceパターンはエンティティとして扱えないものだけを どのように一貫して抽出するのかというのがポイントになりそうだけど、 どの時点で扱えないと判断するのかが明確じゃないように思うので、抽出基準が きちんと定まらず使いにくいんじゃないすかね。 というわけで、おいらは過去から一貫して、トランザクションスクリプト派で、 かつレイヤ的には Pageモデルを使うならば、Page（副次的にActionが入る余地あり
三層アーキテクチャモデル 今回は従来から一般的に言われている三層アーキテクチャモデルについて説明します。 三層アーキテクチャはメインフレーム上でのレガシーシステム時代から提唱され、さまざまな形になってきています。まず、プレゼンテーションレイヤ、ビジネスレイヤ、データレイヤの三層に分ける代表的な例を説明いたします。 ① プレゼンテーションレイヤ層 この階層はシステム操作するユーザに対してのユーザへのインターフェイスを提供します。 この階層にはユーザインターフェイスコンポーネントおよびユーザインターフェイスプロセスコンポーネントが含まれます。 ② ビジネスレイヤ層 この階層にはプレゼンテーションレイヤからデータなどが渡され、業務処理を実行します。 プレゼンテーションからのデータ授受をシンプルにかつ柔軟にするためにサービスインターフェイスを設計します。 ビジネスレイヤでは業務処理を実行するためビ
ひがさんの記事「「誰が書いても同じコード」は大事なことなのか」を読んで思ったことを書いてみる。 大手SIerは独自の重量級の開発プロセスを持つ。 それは多分、メインフレーム＋Cobol時代の開発プロセスを最近のオープン系に焼き直したものに過ぎない。 その現場のプロジェクトは大規模で人数も多いから、少数精鋭チームで自由に動くわけにはいかない。 その開発プロセスの意図は、誰が作業しても同じような品質を保つ所に重点を置く。 つまり、属人性を排除しようとする。 だから、できない人もルーチンのような作業までレベルアップするが、できる人は、無駄なドキュメント作成やマネジメント、そして古臭くなったコーディング規約などの運用ルールに縛られている。 彼らのプロジェクトはタンカーのように、一度動き出したら進路を変えるのは凄く難しい。 現在の特にWebシステム開発では、頻繁なリリースによるバージョンアップが多い
Part3では，もはやオブジェクト指向開発では欠かせない存在となったソフトウエア・パターンについて解説しましょう。デザインパターンに代表される様々なソフトウエア・パターンを活用して，熟練者の経験を盗み，オブジェクト指向開発を円滑に進める術を習得してください。 ソフトウエア・パターンの全貌 皆さんは誰かが書いたプログラムを眺めていて，どこかで見たようなソフトウエア設計やコードに出くわしたことがありませんか？ 「このクラスの役割はどこかで見たことあるなあ」とか「このコードは何度も自分で書いたことがあるぞ」といった感覚です。そのような既視感は，そのコードを書いた人が，皆さんと似たような状況で，繰り返し発生する問題を抱えて，似たような設計/実装を行ったからかもしれません。 ソフトウエア・パターン＊1は，このような繰り返されるソフトウエア設計を集めたものです。それも単に集めたのではなく，様々なソフト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
