WEB+DB PRESS Vol.31 のS2特集で、Goyaについて説明されていたので、Goyaのオブジェクトモデルを図にしてみた。図にしないと覚えられないんです。 ※注　オブジェクトモデルは、Goyaの成果物のひとつであり、Goya自体は要件定義／外部設計／内部設計／実装／テストの工程を対象にした設計指針です。 各クラスを作成する単位は以下のようになる。 画面単位に作成するもの → Action、DTO、Service、DXO 業務ロジック単位に作成するもの → Logic／Rule テーブル単位に作成するもの → DAO、Entity また、Action、Service、DXO、Logic／Rule、DAOは、インタフェースと実装を分離する。 こうして図にしてみると、ServiceがDAOにアクセスするのは、少し違和感がある。ServiceがLogic／Ruleを介さずに、DAOにア

要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 今回はアーキテクチャについてです。 レイヤー構成について、3パターンほど私が考える案を紹介します。 各コンポーネントの役割については、別途説明したいと思います。 Full Pattern 特徴 大規模アプリケーション向け。 コンポーネントを最も細分化したパターン。画面とロジックを分担して共同開発したり、フロー制御や他システム連携が多かったりするシステムに向く。 Serivceがトランザクション境界となる。 レイヤー構成 プレゼンテーション層 Action、Page、Dto サービス層 Service、Dxo ドメイン層 Logic、Dao、Entity Middle Pattern 特徴 中規模アプリケーション向け。 画面ロジックとドメインロジックを2つのレイヤーに集約させたパターン。大抵のシステムは、

今回はアプリケーションの要件にあったデータ処理モデルを決定します。処理モデルとは、データ処理や画面生成をモバイルデバイスとサーバーのどちらが実行するかを定めることです。このモデルを決定することで、アプリの開発環境や実行環境が絞り込まれます。 データを処理する三つのモデル データ処理モデルには、画面転送型、Webブラウザ型、スタンドアロン型の3種類があります（図1）。 画面転送型は、サーバーでデータ処理と画面生成を実行するもので、モバイルデバイスは転送された画面イメージを表示します。デバイス内にデータを保存しないため、モバイルデバイスでよくある紛失や盗難といった課題に耐性があります。 スタンドアロン型は、モバイルデバイスがデータ処理と画面生成を実行するもので、サーバーはモバイルデバイスからの要求に応じて処理を実行します。高速な画面遷移や内蔵カメラ制御などをネットワークに依存せず端末内で処理す

アプリケーション構築を行う場合、前回「システム全体を連続稼働に持ち込め！」述べたとおりハードウェア構成やネットワークなどを把握したうえで構築しなければならない。今回は、さらにその上、ソフトウェアの世界であっても、土台となるアプリケーションサーバが登場してくる。現在、企業向けアプリケーションを構築する場合、「アプリケーションサーバ」という名のミドルウェア上で作成するのがほとんどの場合だろう。このアプリケーションサーバ、果たして本当に理解して利用しているだろうか？ 切っても切れない関係 現在の主流プラットフォームであるJava EE、および.NET Frameworkでは、そのほとんどの機能についてアプリケーションサーバ（またはそれ相当の機能）の存在が前提となっている。 JavaであればJava EE（旧J2EE）対応のアプリケーションサーバだ。.NET Frameworkの場合、IISやMT

運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」Yoshimura Soichiro

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (124件) を見る 社内の有志と一緒に「エリック・エヴァンスのドメイン駆動設計」を読んだので、簡単なまとめと、私がドメイン駆動設計を実践する際の考慮点にも触れてみたいと思います。色々勝手な事を書いています。間違い、勘違いなど多々あるかもしれません。 ドメイン駆動設計とは 業務担当者（ドメインエキスパート）の知識を図式化（ドメインモデル）し、業務担当者と開発メンバーの全員が意思疎通を図りながら設計を行うための手法です。ポイントは以下になると思います。 全員が理解できるようにするため、図は分か

日経ソフトウエア 11月号の特集2で「最新Eclipseで良いJavaプログラムを書こう」に関連する話題として、さらに視野を広げて実用的なウェブアプリケーションでのレイヤー構造とかドメインオブジェクトの関係はどうなるのか？という点について解説してみたいと思います。(まだ日経ソフトウエア11月号を手にしていない方はぜひ買ってくださいw) 結論から先に出しますが、ドメイン駆動設計では一般論として下図のようなレイヤー構造やオブジェクトの関連が提唱されています。 ドメイン層のオブジェクトについては変わりないのですが、ドメイン以外のレイヤーに新しく２つのサービスが登場しているので、まずそこから簡単に説明します。 ドメイン層以外のサービス 実はサービスはドメイン層だけではなく、アプリケーション層とインフラストラクチャ層にも存在する場合があります。その役割を以下にまとめてみました。 レイヤー オブジェク

今回と次回はWebシステム基盤ではなく，その上で動作させるアプリケーションの設計について取り上げます。一般にWebシステム基盤の設計者（Webアーキテクト）とアプリケーションの設計者（アプリケーションSE）は別な担当者であることが多いのですが，アプリケーションはWebシステム基盤と整合性を取っていなければ正しく動きません。整合性を取るために，WebアーキテクトはアプリケーションSEの設計作業を支援することが不可欠で，設計支援するにはアプリケーション設計の知識が必要になります。 アプリケーション設計のポイントは，「アプリケーション・アーキテクチャ」と「アプリケーションの標準化」です。この2点に重点を置いて説明します。 アプリケーション・アーキテクチャ システム全体を見て描いたアプリケーションの青写真を「アプリケーション・アーキテクチャ」と呼びます。アプリケーションを設計する際には，システム基

自分の指向としては、技術の勉強というとDDDとかOODとか、そういう抽象的方面が好きなのだが、オブジェクト指向否定論もあることは承知している。 ---------------追記 2020/09/27 この記事は「ユーザーのメンタルモデルを反映させる」というMVCの本来の設計思想を捉えていません。ただ、巷に流布しているものを元に考えた記事としては資料的には無価値ではないと思いますので、ログとして残しときます。 MVCの本来の考えはOOUIの本や、コプリエンのLean Architecture本が良さそう ------------------------------- 過剰設計の落とし穴 実際、レイヤー構造や業務モデルを頑張って作っているが、実装時に足かせになったり、プログラマがよく規約や方針を理解できずに、ごちゃごちゃに作り、余計に複雑になってしまったりするのは、色々聞く。（自分はこれをや

システムのリソースを柔軟に増やすことができ、従来にない拡張性を実現できるクラウド技術。その特性を生かすには、独特の設計ノウハウが必要です。 そこでここでは、さまざまなクラウド技術の設計ノウハウを、「デザインパターン」としてまとめます。各種のクラウド技術の制約をうまく回避し、性能を引き出す技や、パブリッククラウドでのコスト削減術を、設計のパターンとして示します。 Force.com編 Windows Azure Platform編 Google App Engine編

バッチ処理とは 前回はWebアプリのアーキテクチャ設計の基礎を解説しました。今回はバッチ処理を円滑に行うためのアーキテクチャ設計のポイントを紹介します。 バッチ処理とは、蓄積された複数件のデータを、まとめて一括処理する処理形態のことを指します。このような処理形態においては、大量データの処理を一定時間以内に完了させるためのアーキテクチャを、さまざまな角度から検討していく必要があります。 また、画面オンライン処理とは異なり、ユーザーとの対話なく処理が進められます。よって、バッチ処理の途中でエラーが発生した場合の対応を考慮して、アーキテクチャを設計しなければなりません。バッチ処理の基本についてより深く知りたい方は、下記参考記事をご参照ください。 参考リンク:鉄板焼のお店から学ぶ、バッチ処理"超"入門（＠IT） バッチ処理におけるアーキテクチャ設計時の検討ポイント バッチ処理のアーキテクチャを考え

複数回のリクエスト/レスポンスを束ねる Webブラウザ上の操作をリクエストとしてHTTPDに届け，レスポンスの内容をWebブラウザで表示する。こうした仕組みはシンプルで理解しやすいが，実際のシステムでは問題が生じることがある。 例えば電子商取引サイトで商品を購入する場合を考えよう。商品画面でモノを選んで［購入］ボタンを押すと，バスケットの内容を一覧表示する確認画面が現れ，［購入］ボタンを押すと発送先や支払方法などを指定する決済画面が表示される。この場合，商品画面で選んだモノの情報を確認画面に，確認画面で承認したことを決済画面に，それぞれ引き継いでいく必要がある。こうした処理を実現するには，特定のWebブラウザから送られてきた一連のリクエスト/レスポンスをまとめて扱うことが必要だ。この一連のリクエスト/レスポンス群を「セッション」と呼ぶ。 Webシステムでは，セッションをどのように管理するか

アーキテクチャは3種類 まずは，情報システムの基本アーキテクチャを簡単におさらいしたい。主な基本アーキテクチャには，ホスト・システム，クライアント/サーバー（C/S）システム，Webシステム――の3種類がある。 ホスト・システムは，「ホスト」と呼ばれる大型コンピュータで集中処理する。ホストに接続した「端末」はあるが，画面表示と通信を担当するだけで，業務処理は実行しない。ホスト・システムは，情報システムの黎明期から実績を積み重ねているので，システム全体の堅牢性が高く，今日でも多用されている。 これに対してC/Sシステムとは，「クライアント」と「サーバー」（一般的にはデータベース・サーバー）という二つの要素で構成し，それぞれで業務を分散処理する。サーバーの負荷が軽くなるので，ホストに比べてハードウエアは小型・安価・低スペックで済む。オープン系（UNIXやPC）システムで多用されてきたが，構築や