ソフトウェアアーキテクチャでありがちな間違いトップ10Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
デスマーチ撲滅への「飛躍」なるか--大手SI事業者、外部設計書の記述を標準化
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます デスマーチはデスマッチになりやすい――。SI業界でよく言われることだ。しかし、そのデスマーチを撲滅するための即効薬は、いまだ存在しない。そうしたなかで、デスマーチを撲滅するための「小さな一歩だが、大きな飛躍」と関係者から期待されている文書類が公開された。 NTTデータなど大手SI事業者6社が2006年4月から共同で立ち上げた「実践的アプローチに基づく要求仕様の発注者ビュー検討会」（発注者ビュー検討会）の第1弾の成果物がこのほどウェブで公開されたのである。同検討会には、NTTデータのほか、富士通、NEC、日立製作所、構造計画研究所、東芝ソリューションの計6社が参加している。 発注者ビュー検討会は、情報システムの仕様について、ユーザー企業に
階層化アーキテクチャと依存性注入・依存性逆転：CodeZine
.NET 1.0のベータ1から.NET Frameworkに従事してきた.NET開発のエキスパートで、アプリケーションのアーキテクチャ作成と設計と開発で7年以上の経験がある。アジャイルプラクティスと実際的なビヘイビア駆動開発（BDD）テクニックを通じてチームの成功を支援する独立コンサルタントとして活躍している。BDDを.NETに応用する記事をVisual Studio Magazine、DevX、MSDNに寄稿。ポッドキャスト/スクリーンキャストとして人気のある.NET Rocks!とDNRTVに登場したことがあり、実際のデザインパターンというトピックについてMicrosoftのためのウェブキャストを配信。MSDN Canada Speakers BureauおよびMicrosoft Most Valuable Professional（MVP）のメンバ。自分のブログも継続的に更新中。
ひがやすを blog - [etc]トランザクションスクリプトとドメインモデル
このネタについては、ループしやすく結論が出ないので、あまり書きたくはないのですが、私の考えを誤解している人が多いようなので、書いておきます。 トランザクションスクリプト、ドメインモデルなんてのは、所詮実装の話で、どっちもどっち。トランザクションスクリプトが良いわけでもないし、ドメインモデルが良いわけでもない。私はどっちも好きではない。 重要なのは、ユースケース(ユーザ要件)と実装の対応関係が明確になっていることです。それさえ満たされていれば、実装はどうなっていてもかまわない。 ユースケースと実装の対応関係を明確にする方法の一つとして、ユーザ機能レベルのユースケースは、Teedaでいうサブアプリケーション(関連する複数の画面を束ねたもの)にマッピングする。サブアプリケーションは、関連する各画面の親クラスに相当する。各画面は、サブ機能レベルのユースケースに相当し、サブ機能レベルのユースケースは
![ひがやすを blog - [etc]トランザクションスクリプトとドメインモデル](https://cdn-ak-scissors.b.st-hatena.com/image/square/8e78530571d6b2a4e4f7daa905c8574b19154a4d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117126970898857%2F17680117126970927152%2F1550549907)
ひがやすを blog - ドメインモデルに対する日米の温度差
ドメインモデルに対する日米の温度差 ひさびさにみたなぁ、この話題と思いつつ、コメントします。 昔書いた自分の記事をすべて読み返したわけではありませんが、どこにもトランザクションスクリプトが良いと書いたことはないはず。 この話題に関する問題の根源は、ファウラーが トランザクションスクリプトは、単純だから単純なシステムには向いている。でも、複雑な問題を扱うには、真のオブジェクト指向であるドメインモデルを使ったほうが良い。としたところにあると思います。これが、そもそもおかしい。複雑なシステムを扱うには、ドメインモデルのほうが向いているというのは根拠がない。データと振る舞いを一つにまとめることがオブジェクト指向というのも単純すぎる。 別にオブジェクト指向はこうあるべきなんていまさら議論するつもりはありませんが、私の中でのオブジェクト指向は、「それぞれのオブジェクトがきちんと割り当てられた責任を果た
モデリング・リファクタリングのススメ
ビジネス・モデリングなどのモデリングを始めてはみたものの，なかなか上手くモデリングできない…そんな悩みを持っている方も多いと思います。そこで，今回はモデリングを上達させるための「モデリング・リファクタリング」という方法をご紹介します。 モデリング・リファクタリングとは 「モデリング・リファクタリング」とは筆者が考えた造語です。（すでに誰かによって提唱されているかもしれませんが）筆者が発明したものではなく，モデリングに慣れている方なら自然とやっているようなテクニックです。 もともと「リファクタリング」というのは，小さなプログラム（例えばクラス）を作るときに，プログラムの外側の仕様（使われ方）は変えずに，中身の構造だけを変えることです。 なぜそんなことをするかというと，とりあえず仕様は満たしていたとしても，中身が汚い設計のままでは，変更に弱く，保守性も悪いからです。そこで，小さなプログラムを作
コンパイラの入り口、「字句解析」のための文字列操作
前回はBNFでプログラム言語S1sを定義しました。今回は、この定義に従って記述されたプログラムをコンパイルするに当たり、最初に実行する処理である字句解析について解説をします。 「字句解析」とは何ぞや？ 前回、プログラミング言語S1sを次のように定義しました。 <program> ::= main '{' <expression> '}' <expression> ::= <term>{ <opeas> <term> } <term> ::= <factor>{ <opemd> <factor> } <factor> ::= <number>|( <expression> ) <number> ::= <digit>{<digit>} <opeas> ::= + | - <opemd> ::= * | / <digit> ::= 0|1|2|3|4|5|6|7|8|9 この定義から、S1sの
Tags: Database schemas
An online tech community is the most exciting place for a software developer to spend their time. It not only offers the chance to work and interact remotely, but also helps in honing one’s own skills and becoming a well-rounded programmer. Whether you are a budding software developer or simply passionate about technology, here are the best online software development communities you can join. The
ひがやすを blog - EJB3時代のアーキテクチャパターン
EJB3、JSF、JPAを使ったときのアーキテクチャは､ある一定のパターンで説明できると思っています。私見ですが､説明したいと思います。 まず、プレゼンテーション層であるJSFですが、ページ(View)ごとにManagedBean(s)を定義します。ManagedBeanの作り方は3パターンあり イベント処理専用(Action)でモデルとしてはEntity(ドメインモデル)を使う(Action only) イベント処理とプレゼンテーションモデルを兼用(Page only。Pageでイベントも処理) イベント処理(Action)とプレゼンテーションモデル(Page)を分離(Action + Page) があります。 私は､ドメインモデルは､ドメイン層でのみ使い､プレゼンテーション層では､専用のプレゼンテーションモデルを使うべきだと思っています。なぜなら、ドメイン層とプレゼンテーション層では､
システムの論理設計を構造化するための視点 - 設計者の発言
業務システムの論理設計を構造化するためのさまざまな視点がある。それらの意味合いを区別しないままに設計情報を漫然と眺めるだけでは、読み手として重要な項目を読み落とすし、設計者として複雑膨大な設計情報を「分割して統治」することにも失敗する。 「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」をとりあげて、システムのあり方を眺めるためのいろいろな視点を見てみよう。 ◆業務フローの視点で眺める ＸＥＡＤにおいてシステム定義は、ツリービュー上の「業務フロー」、「職種別担当業務」、「サーバーモジュール」の３つのまとまりとして示される。ひとつめのまとまりの「業務フロー」の下位には、「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」では「現預金口座管理の流れ」、「手形管理の流れ」、「売上収益回収の流れ」といった１６個の要素（ノード）が並んでいる。それぞれのノードを選択すると、データフローダイアグラム（ＤＦＤ）でまとめられた「業務（後
MVC - MVCとはModel-View-Controllerの頭文字をとったものです。
MVC - MVCとはModel-View-Controllerの頭文字をとったものです。 目次 新着情報2004 MVC関連リンク MVCと３層C/S 関連モデル PAC - Presentation - Abstraction - Controller Document - View architecture MVC発祥の地では 雑談 MVCとはModel-View-Controllerの頭文字をとったものです。 新着情報2004 月刊DBマガジン6月号にModel2+の解説があるらしい。（ニュースソース[jfriends-ml 11123] Model2+） MVC関連リンク MVCモデルという言葉をよく聞きますが何のことですか？ http://www.atmarkit.co.jp/fjava/javafaq/j2ee/j2e07.html 使わないと損をするModel-View
「テストを最初に書くことのメリット」？ - dann's blog
http://d.hatena.ne.jp/thata/20050823#1124765700 僕が開発をする場合はインターフェースから書き出すことは最近はまずないです。インターフェースを検討するために実装から書き始めます。ある程度実装をして試行錯誤してみてから、インターフェースを書きます。 何故かと言うと、ラフスケッチがないと、本当のインターフェースが見えてこないからです。 僕がTDDを試してみて思うのは、TDDでは試行錯誤の段階がないために、インターフェースの修正を初期段階で頻繁に繰り返すことになるのでロスが大きいということです。 だから、ラフスケッチにTDDは向いていないんじゃないかなと思っています。検討する度にassertionと実装を変更するのは速度が遅く、ラフスケッチには向かないと思っています。 TDDの感覚は、僕にはどうもいきなり本番書いているような感じがしてどうもしっくりき
「保守しやすい」ことが、良い設計(EoM = Ease of Maintenance)：An Agile Way：オルタナティブ・ブログ
前２回で、オブジェクト指向を「テスト容易性」と「変更容易性」を中心に再定義したい、という話をした。 従来オブジェクト指向の説明に使われている概念、およびそこから得られる（といわれている）再利用性という品質からではなく、 テスト容易性： EoT = Ease of Testing 変更容易性： EoC = Ease of Changing という２つの概念からが、（現代的な）オブジェクト指向設計の焦点であることを主張してきた。最後、なぜこの２つが必要なのか、というと、それは、メンテナンスのしやすさ（EoM=Ease of Maintenance）を高めるからだ。そして、このEoMこそが、2005年のソフトウェア開発の根本品質だ、と言い切ってまとめたい。 EoMの高い設計が、よいオブジェクト指向設計である。 ということである。今回は、前回書いた、EoT/EoCそして、このEoMについて、ソフト
「変更しやすい」ことが、良い設計 (EoC=Ease of Changing) - An Agile Way [ITmedia オルタナティブ・ブログ]
前回は、EoT(Ease of Testing: テスト容易性)によってよいオブジェクト指向設計を再定義したい、という表明をした。今回は、二本目のナイフを抜きたい。キーワードは、EoC(*1)(Ease of Changing)、変更容易性だ。 この記事では、 EoCの高い設計が、よいオブジェクト指向設計である。 と主張したい。設計品質の中で、「変更容易性(EoC)」を最上位と見る。 ここ10年のオブジェクト指向の最大の失敗は、「再利用性」をその最大の価値、として説明しようとしてきたこと。そして分かったことは、再利用がその努力コストに見合う効果がでることは極めて稀であること、また、テクノロジではなくソーシャルな活動が再利用に効くこと、さらに、コードの再利用ではなく、ナレッジの再利用（例えばパターン）の方が、まだ可能性があるということ（少なくとも2005年のコンテクストでは）。 再利用性では
「テストしやすい」ことが、良い設計(EoT=Ease of Testing) - An Agile Way [ITmedia オルタナティブ・ブログ]
良い設計とはなにか、と問われて、凝集度と結合度に関する議論を思いつく人も多いだろう。しかし、この定義によりもっと具体性がある設計方針として、テストを考える。テストの視点によってオブジェクト指向を再定義したい。キーワードは、Eon(Ease of Testing)、テスト容易性だ。 ぼくは、 EoT(*1)の高い設計が、よいオブジェクト指向設計である。 と主張する。設計品質の中で「テスト容易性(EoT)」を最上位と見るのだ。オブジェクト指向のさまざまな機構、用語、考え方は、すべて EoT のため、と捕らえられる。例えば、
＠IT：J2EE Watch [7]
J2EE関連の最新トピックをわかりやすく解説 J2EE Watch ［7］ DIとAOPがサーバ・コンポーネント技術を変える スティルハウス 吉川和巳 2005/6/16 ■DIコンテナ＝軽量コンテナ？ 周知のとおり、DIコンテナとは、DI（Dependency Injection／依存性注入）の技法によりコンポーネント開発を一段と容易にするコンテナを指します。代表的なDIコンテナとしてはSpringやSeasarなどが有名です。これらのDIコンテナは、EJBのような「重量級のコンテナ」によるコンポーネント開発の困難さを打開するために生み出されたもので、しばしば「軽量コンテナ」と呼ばれます。 とはいえ最近では、EJB＝重量コンテナ、DIコンテナ＝軽量コンテナという単純な図式ではなくなりつつあります。例えば、標準化作業が大詰めを迎えているEJB 3.0では、DIの全面的な導入によって、EJB
What Is Software Design? by Jack W. Reeves - developer.*, Developer Dot Star
This is Part One of Code As Design: Three Essays by Jack W. Reeves. Click here for the introduction. This essay first appeared in the Fall, 1992 issue of C++ Journal. Object oriented techniques, and C++ in particular, seem to be taking the software world by storm. Numerous articles and books have appeared describing how to apply the new techniques. In general, the questions of whether O-O techniqu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
compiler resume "Garbage Collection"
設計者の発言−渡辺幸三ブログ
