最後に，設計/アーキテクチャの不具合で火を噴いたプロジェクトの火消し術を取り上げよう。この場合の主な対処法は，（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ページを開く
