ソフトウェアアーキテクチャでありがちな間違いトップ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が最近リリースされ、重要な変...
階層化アーキテクチャと依存性注入・依存性逆転：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）のメンバ。自分のブログも継続的に更新中。
たかのり日記 - [Seasar2][Teeda]Teeda Extension featuring Goya ～要件定義～
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 普段使用されている手法で問題ありませんが、Teeda Extensionの強み／弱みを知らないと、後で苦労することになると思いますので、ここでは、その点について紹介したいと思います。 また、一般の要件定義レベルよりは、後工程でのリスクを軽減するためにも、実装に近いレベルで書きたいと思います。 ※2007/02/11時点 Teeda Extensionの特徴 JSF拡張 JSFの仕様をベースに、JSFの使いづらい点を拡張したフレームワーク。 ページ駆動開発 HTML画面を起点に開発を実施する。画面とそれに関連するデータや処理を、1対1で開発するスタイルを採用しており、画面と画面遷移のアンマッチを解消している。 HTMLテンプレート Viewのテンプレートを標準的なHTMLだけで記述することが可能。これまで
![たかのり日記 - [Seasar2][Teeda]Teeda Extension featuring Goya ～要件定義～](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
ひがやすを blog - EJB3時代のアーキテクチャパターン
EJB3、JSF、JPAを使ったときのアーキテクチャは､ある一定のパターンで説明できると思っています。私見ですが､説明したいと思います。 まず、プレゼンテーション層であるJSFですが、ページ(View)ごとにManagedBean(s)を定義します。ManagedBeanの作り方は3パターンあり イベント処理専用(Action)でモデルとしてはEntity(ドメインモデル)を使う(Action only) イベント処理とプレゼンテーションモデルを兼用(Page only。Pageでイベントも処理) イベント処理(Action)とプレゼンテーションモデル(Page)を分離(Action + Page) があります。 私は､ドメインモデルは､ドメイン層でのみ使い､プレゼンテーション層では､専用のプレゼンテーションモデルを使うべきだと思っています。なぜなら、ドメイン層とプレゼンテーション層では､
naoyaのはてなダイアリー - Inside Hatena Bookmark's Backend の資料
以下に置いておきました。遅くなってすいません。 http://bloghackers.net/~naoya/pdf/050404inside_hatena_bookmark.pdf 会場で前置きしたように、はてなブックマークは、はてなで一番大きなシステムであるはてなダイアリーあるいは同じ YAPC で発表のあった mixi に比べると、まだそこまで大きな規模ではありません。月間の PV はだいたい 4,000 万 PV 〜 というところです。 ただ、日本でのトラフィックが上から 5 番目みたいな怪物サイトよりも、月間の PV が 1,000 万クラスのサービスの情報の方が、より現実的で役に立つのではないかと思い、はてなブックマークの裏側に絞って話しをしてみました。 ...という前提で見ていただけると嬉しいです。 はてなブックマークのデータのサイズもかなり大きくなってきたので、ぼちぼちパーテ
ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」：ITpro
ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」 YAPC::Asia 2006 Tokyo 東京都大田区で開催されているPerl技術者向けカンファレンス「YAPC::Asia 2006 Tokyo」で2006年3月29日，日本最大のソーシャル・ネットワーキング・サイト（SNS）である「mixi」を運営するミクシィのBatara Kesuma（バタラ・ケスマ）取締役最高技術責任者（CTO）が，増え続ける膨大なトラフィックにどのように対処してきたのかについて講演した。カギとなるのは「データベース分割」である。 mixiのシステムはもともとBatara氏が1人で作り上げたものだ。2003年当時，米国でFriendsterなどのSNSがはやっており，同氏が会社（現在のミクシィ，当時はイー・マーキュリー）にSNSを作りたいと提案したところ認められたという。同氏が
エンタープライズAjaxアーキテクチャ - FAX
エンタープライズAjaxアーキテクチャ 技術 Ajax時代の、サーバ＜-＞クライアントで協調するMVCフレームワーク：Goodpic 上記リンクにより考えた構成が以下図。 要点は、クライアント側へアーキテクチャが2階層シフトすることだろう。 レイヤ間のデータフォーマットは、効率と取り回しやすさからJSONが有力か。 サービスがステートを持つ必要があるように思える。 State of Ajax: Progress, Challenges, and Implications for SOAs 上記はSOAを中心とした発想。「SOA無くして、Ajax無し*1」 クライアントに力がついた上では、サーバーのコントローラは不要になる。 JavaScriptのテンプレートJST。「ご一緒にポテトはいかがですか?」でも使われている。 このクライアント側の構成は、モックデータ(JSON、HTML、CSV)を
アーキテクチャの採用理由を説明できるか？
「なぜこのアーキテクチャを採用したんですか？」 「いや、なぜって……。いま作るならこれがいま一番はやってるからなんですけど……」 「このシステム、5年はこのまま改修しながら使い続ける予定なんですけど、もちろんそれは考えてのことですよね!?」 「いや、ちゃんと現場を教育し続ければ可能だと思うんですよ、第一……」 「できる、できないの話じゃないんですよ。じゃあ一体その教育コストと時間は誰が払うんですか？ あなた、払ってくれるんですかね？」 「いや、それは……」 「あなたの趣味で作られたら、運用する側はたまったもんじゃないんですよ。私のいってること、理解できますよね？」 「いえ、そもそもソフトウェアというのはオブジェクト指向に基づいてこう作るべきというのが最近の考え方で……」 「あんたから大学の授業みたいなのを聞きたいんじゃないんだよ、もういい。帰って」 冒頭から修羅場のシーンを書いてしまったが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クラシックJ2EEアーキテクチャーからの脱却