[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
Architect also implementsなのだ。 - 2008-10-28 - おおたに6号機blog
アーキテクトとか言うと何様的に思う人もいるかもしれませんが、全体構成を決めるという 意味でアーキテクトは重要なロールです。ロールなので実体が誰であるかはともかくとしても。 アーキテクチャとは何か、その深淵な話題に自分が触れられるほどのもんだとは とても思えないですが、下記の平鍋さんと萩原さんのお話は読んでおくべきことだと感じました。 実際にXPなどの手法でアーキテクチャは段階的に育てていく人と、ある程度初期から形を作りこむ人といますが、 実際に作るときにはそのバランスを取るはずです。 アーキテクチャを決めないで実装の結果をアーキテクチャですとすると、それを使う方が変わっていく様が 激しすぎてついていけないというリスクがある。アーキテクトの一存とその実装方法にゆだねられてしまう。 かといって、アーキテクチャをがっちり決めすぎる（所謂BDUF（Big Design Upfront)）と、今度は
ドメイン層に最適なアーキテクチャを考える
サービス層が持つべき機能とは 次にドメイン層について考えて見ます。サービス層は、業務サービスを実現する層です。サービス層はドメイン層に存在するビジネスロジックを利用してサービスを実現するためのサービスプロセスを実現しています。 そして、トランザクションの制御、セキュリティなどのシステム機能を実現します。 このとき業務機能（機能要件）とシステム機能（非機能要件）を実現する実装は、分離できるようにします。一般的にはEJBやAOPなどのフレームワークを利用し、ビジネスロジックにシステム機能が混在しないようにします。 ドメイン層の設計をどのように考えるか ドメイン層は、ビジネスロジックを実装します。ビジネスロジックは、必要とするデータとともにエンティティクラスにカプセル化されます。これは、オブジェクト指向分析で作成された概念モデルを基に作成します。各エンティティクラスは、継承、インターフェイス、関
PofEAA's Wiki - (ファウラー | 読書会)
PofEAAのWikiです。Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、 パターンカタログの翻訳を行っています。bliki_jaと同じくどなたでも参加可能ですので、是非参加してみてください ;-) ※このサイトは書籍の邦訳とは一切関係ありません。 ■ PofEAAのパターンカタログ and PofEAAのパターンカタログ(邦訳版)ここから読み始めるとよいでしょう。対応表もあります。 ■ 読書会 第12回の開催予定は未定です。 ■ PofEAA読書会メーリングリスト読書会に関する話題を扱っていますが、読者会への参加を強制するものではありません。興味のある方の参加は随時受け付けています。
生産性（続き）、アーキテクチャとフレームワーク (arclamp.jp アークランプ)
前回のエントリから時間が空いてしまいました、ごめんなさい。せっかくひがさんとkoichikさんにコメントをいただいたので整理します。 ひがさんのコメントが象徴的だと思っていて、 選ぶことが大事じゃなくて作ることが大事なのでは。 という点で、僕は「選ぶことが大事だ」と思っています。そもそも僕はひがさんやkoichikさんのように「（フレームワークを）作る」力がない（気持ちとか、そういうのも含めて）。 なので、koichikさんの 規模で世の中の 80% を占めるところのエンタープライズシステムでは Spring の方が生産性を高められる＜中略＞の根拠たり得る説得力ある意見が聞きたかった については、「選ぶ」という視点ではSpringの方が最適化されているからという答えになります（ここまで断定的な言い方をしているつもりはなくて、『そういう場合が多い』というぐらいだけど）。 「規模で世の中の 8
Railsが成功しEJB3が失敗したわけ - ひがやすを技術ブログ
Railsが成功し、EJB3が失敗したわけは、イノベーションへの解にでてくる「独自仕様の製品アーキテクチャ」と「モジュール方式のオープンな業界標準」の考え方で、うまく説明できるように思えます。 ただし、この手の話は、理論にあうように現実を説明しているところがあるので、あくまでも、1つの可能性として聞いてください。 ここでの重要な考え方は、「顧客のニーズ」と「製品の性能」の力関係です。 「顧客のニーズ」が「製品の性能」を超えている場合は、顧客は、製品の性能向上に価値を認め、お金を払います。このときに企業として、成功しやすいソリューションは、「最適化された独自アーキテクチャ」で望むことです。性能を向上させるためには、独自アーキテクチャのほうが、いろいろ工夫ができるためです。 「製品の性能」が「顧客のニーズ」を超えている場合は、顧客は、製品の性能向上に価値をあまり認めません。既に、製品の性能に満
第1回 階層化アプリケーションとは | gihyo.jp
小規模～大規模のシステム構築を検討するにあたり、システムを階層化して構築することが多くなっています。人は、複雑なものをまとめて理解することはできません。そこで、階層化しそれぞれの階層に意味づけを行うことにより対象物を理解しようというわけです。そこで本連載では、今さらかもしれませんが、n階層アーキテクチャアプリケーションについて説明したいと思います。 n階層アーキテクチャアプリケーションのメリット・デメリット n階層化アーキテクチャとは、アプリケーションを表示、業務処理、データ等、複数の階層で分割する分散アプリケーション設計手法のことを指します。 階層化にはどのような視点で分割するかによって、大きく「論理的役割」による分割と「物理的役割」による分割に分類できます。 論理的役割による分割とは、画面表示部、業務ロジック部、DB、ファイルなどのデータ格納部といった各階層の役割を意識して分割される場
Facebook Platformから見る、次のアーキテクチャ (arclamp.jp アークランプ)
Facebookの認知度は上がってきていると思います。2007年5月にFacebook Platformを発表して以降は「次世代のソーシャルOS」というラベルが貼られ、その動向が注目されています。10月24日にはMicrosoftが2億4000万ドルを出資し、評価額は150億ドル（1.7兆）に跳ね上がりました。また、11月2日に発表されたGoogleのオープンソーシャルに対しては当然のように参加を表明していません。 Facebook Platformとは Facebook Platformはサードパーティの開発者がFacebook上の情報を利用してアプリケーションを開発できる仕組みです。それだけならデータベース型ですが、加えて開発したアプリケーションはFacebookに登録することが可能です。Facebookユーザーはアプリケーションの一覧から欲しいアプリケーションをクリックするだけで自
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
八角研究所 : ユーザインタフェースとアプリケーションは分離する