運営元のロゴ 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本が良さそう ------------------------------- 過剰設計の落とし穴 実際、レイヤー構造や業務モデルを頑張って作っているが、実装時に足かせになったり、プログラマがよく規約や方針を理解できずに、ごちゃごちゃに作り、余計に複雑になってしまったりするのは、色々聞く。（自分はこれをや

MementoWeaver開発記 一応、MWも一通りの機能はコーディングが完了したので、少し気になっていたところの見直しを行い始める。 まずは例外設計の見直しから。 Javaの例外設計については、皆様一家言あるかもしれないが、MWについての課題認識と対応方針を以下に記載する。 現状の課題認識 現状では、アプリで送出する例外クラスとしてMWException(チェック例外)を定義しているが、以下の点でいけていない。 ほぼ全てのメソッドシグニチャにthrows MWExceptionが含まれていて、 結局何もハンドルしていない コードが冗長 ミソもクソも全てMWExceptionなので、ビジネスロジック観点からの例外とシステム環境に起因する例外が区別できていない。 MWにおける例外設計の方針 上記課題認識を踏まえて、MWの例外設計については以下の方針で見直すこととする。 ビジネスロジック観点か

ユーザとのインタフェースが原因で発生するエラーは、プログラム内でエラー対処ができないので、ユーザに誤りを知らせ、正しい方法で操作をやりなおすことを促します。 プログラム内のバグが原因で発生するエラーは、ユーザには対処できません。プログラム外部の異常が原因で発生するエラーは、ユーザが正しく操作し、プログラムにバグがありません。 エラーの対処 ユーザとのインタフェースが原因のエラーに対しては、ユーザに誤った入力・操作を取り消し、正しい入力・操作をやりなおしてもらうことが対処になります。 そこで、ユーザに対して何が間違ったのかを指摘して、正しい入力・操作を示す必要があります。通常は、エラーが発生した直後にユーザインタフェース（画面）を用いて知らせます。たとえば、「⁠日付の指定が間違っています。予約日は本日から30日以内で指定してください」のように示します。よく見かける、「⁠不正な操作です」「⁠内

プログラマの宿命！ 例外とエラー処理を理解する：【改訂版】Eclipseではじめるプログラミング（23）（1/3 ページ） これからプログラミングを学習したい方、Javaは難しそうでとっつきづらいという方のためのJavaプログラミング超入門連載です。最新のEclipseとJava 6を使い大幅に情報量を増やした、連載「Eclipseではじめるプログラミング」の改訂版となります（この回と次回のみ、別連載「EclipseでJavaに強くなる」の改訂版です。今回は第3回「EclipseでJavaの例外を理解する」の改訂版です） プログラマの“宿命”、「例外」を究めよう！ Javaでは、エラーへ対処する処理を記述するための仕組みとして「例外」というものがあります。データの入出力を伴うプログラムでは、基本的に例外を使ったプログラムを作成する必要がありますから、よく理解しておきましょう。 また、この仕

はじめに システム開発において例外処理は重要なポイントですが、あまりに軽視されているのが現状ではないでしょうか。本稿では、これまでの著者の開発経験の中から培った汎用的な手法を説明します。 この記事は「美しい設計」ではなく「現実的な設計」、現場に適用できる「できるだけ手間の少なく、汎用的な設計」を目指しています。 対象読者 J2EE開発者・アーキテクト。特に業務システムの開発現場の方が対象です。 必要な環境 概念の説明が中心ですので、開発環境は必要ありません。 エラーの分類 実装時に考慮すべきエラーは2つに大別できます。 想定内でトランザクションの実行開始前にチェックするエラー。主に入力エラー。 異常な状態としてトランザクションの続行が不可能なエラー（例外）。 前者については、例外を使うべきではありません。入力チェックエラーを表現するには、ステータスコードを使うべきです。理由は次のとおりです

エラーの種類 さて、単純にエラー処理と言っても、その種類によって対応方法が違ってきます。本記事では、エラーを次のように分類することとします。 業務エラー 単体入力エラー 突合せエラー システムエラー それでは、それぞれのエラーについて詳しく説明していきましょう。 業務エラー アプリケーション側で想定可能で、発生しても以後の処理に復帰できるようなエラーを、「業務エラー」と呼ぶこととします。業務エラーはさらにそのチェック方法によって、単体入力エラー、突合せエラーに分けることができます。 [1] 単体入力エラー ユーザーがフォームに入力した値のみでチェックが可能なエラーを単体入力エラーと呼ぶこととします。例えば、必須項目が入力されていない、数字を入力すべき項目に数字以外が入力された、などです。 また、複数の項目を組み合わせてチェックするものについても、単体入力エラーに分類します。例えば、日付の前

ユーザにとってエラーの対応はプログラムの品質(完成度)を印象付ける大事な要素になります。 エラー処理が無いプログラムは無いと思いますが、大きなプロジェクト以外では暗黙の対応が多いように思います。暗黙の対応とは、製造時にプログラマーがエラー処理を追加していくことです。 この場合は、システムによりエラーの対処方がまちまちで処理の抜けや製造後に追加した為にソースコードの可読性が落ち保守性が悪くなります。保守工数を減らす為にもエラー処理を設計する必要があります。 エラー処理は、システム上のエラーのほかに、業務上の問題やユーザの操作ミスなどを抑制するように処理を設計します。このため、基本設計段階で大局的な観点からエラー処理を設計します。 エラー設計項目