エンタープライズアプリケーションの例

ソフトウェア開発にもいろいろある。
具体的なアプリケーションをあげると...

エンタープライズアプリケーション



給与計算、診療記録、出荷管理、コスト分析、信用調査、サプライチェーン、
会計、顧客サービス、外国為替取引、...

エンタープライズアプリケーションでない



自動車用燃料噴射制御、ワープロ、エレベータ制御、化学プラント制御、
電話交換、OS,コンパイラ、ゲーム

簡単に言うと



データベースがあって、入力フォームがあって、裏でバッチ処理が走る。
これが、エンタープライズアプリケーションかな?

最近は、他のシステムとの連携も多い。
  • ファイル交換
  • データベース共有
  • リモートプロシージャコール
  • メッセージング


InfoQ と エンタープライズアプリケーション

知る人ぞ知る、アーキテクト向けのサイト、InfoQ を見ていて、ちょっと気がついたこと。

本家のInfoQ
日本のInfoQ

ページトップのキャッチを比べてみる。

本家:Tracking change and innovation in the enterprise software development community
日本:最新技術を追い求めるデベロッパのための情報コミュニティ

英語の enterprise が、日本では割愛されていますね。

日本のデベロッパには、Enterprise がキャッチではなくて、英語圏のデベロッパには、Enterprise というのがキーワードの一つになっている。

多くの日本のIT技術者にとっては、エンタープライズソフトウェアは、関心事じゃないんでしょうね。
Domain-Driven Design が、アメリカでの評判・影響と、日本での評判・影響にずいぶん違いがあると感じていた。

この InfoQ のキャッチの違いも、同じところに理由があるんでしょうね。






エンタープライズアプリケーションとは?

いろいろなエンタープライズ


ソフトウェアの世界では、いろいろ目に付きますね。

J2EE
エンタープライズエディション
EAA
エンタープライズアプリケーションアーキテクチャ
EIP
エンタープライズインテグレーションパターン
ESB
エンタープライズサービスバス


私は、自分の専門分野は、ソフトウェアシステムの中でも、エンタープライズ分野、であると自負している。

マーチン・ファウラー、かく語りき


著書、PoEAA ( エンタープライズアプリケーションアーキテクチャ ) の「はじめに」で、マーチンファウラーは、エンタープライズアプリケーションの意味を説明している。
明確に定義できないし、人によって使い方がいろいろある、あいまいな言葉。
私としては、このマーチンファウラーの説明が、いちばんしっくり来ている。

最初の段落の以下の2点にすべてが要約されている。
  • 複雑なデータに対処する
  • (論理的とはいいがたい)ビジネスルール


エンタープライズアプリケーションの関心事は、「データ」と「ビジネスルール」というわけだ。

永続データ、たくさんのデータ、同時データアクセス


データの問題を、三つの視点から、とりあげている。

永続性


ビジネスは、情報の記録と保管は、基本中の基本。アプリケーションソフトウェアを入れ替えても、既存のデータは「移行」して使い続ける。

たくさんのデータ


ビジネスで扱うデータは、どんどん増えている。なんでもかんでも、電子化・デジタル化の時代。
インターネット時代では、顧客のワンクリックまで、記録して、永続化する。
こういう膨大なデータを効率良く扱うのがエンタープライズアプリケーションの、重要な関心事。

同時データアクセス


これも、ネットワーク時代になって、加速している問題。
同じデータに多くの人が同時にアクセスする。同じデータを同時に書き換えることも起きる。
これをどうやって、うまくさばくか?

RDBMS と SQL


永続化、大量データ、同時アクセスを実現する技術としては、いまのところ、RDBMS と SQL が基本の技術。
RDBMS/SQLの使った、良い実践とはなにか? 良い設計とは? 良いアーキテクチャとは?
これが、エンタープライズアプリケーションの重要な関心事の一つ。

多くのユーザインタフェース画面


エンタープライズアプリケーションとは、極端に単純化すると、データベースを、CRUDするもの、と定義できる。

データの種類や量が多いということは、CRUDのための画面も多いということ。
また、いろいろなビジネス上のルールがあるために、ユーザによって、「できる・できない」「見える・見えない」を変えなきゃいけない。
Web アプリケーションを顧客に使ってもらうとなると、顧客ごとに、さらに、カストマイズした画面が欲しくなる。

検索フォーム・一覧・入力フォーム。基本はきまりきった単純な形式しかないのに、とにかく画面数が膨れ上がる。
どうやって、これを簡単に開発するか?
変更要求があったときに、どうやって、安全・確実に変更を適用するか?

電子メールというユーザインタフェースもいろいろ必要。
携帯電話や、PDA 用も。

画面の爆発です。
でも、ユーザにとっては、画面こそ、画面だけが、システム。
ここが、がんばりどころとなるわけだ。

バッチ


バッチ処理も忘れちゃいけいない。
ビジネスでは、日、週、月、四半期、半期、年度、というサイクル構造(=バッチ処理のタイミング)は、強固な枠組です。

他のエンタープライズアプリケーションと統合


あちこちで、爆発的に、ビジネスデータの電子化が進んでいる。
それも、同時多発ゲリラのように、さまざまなデータ形式、実装技術でやまほどエンタープライズアプリケーションが作られている。

社内だけでもたいへんなのに、最近は、ネットワークのおかげで、社外とのシステム連携も、日常的な課題になってきた。
ビジネス活動とは、人と人、組織と組織の相互作用。だから、ビジネスの道具である、エンタープライズアプリケーションも、他のアプリケーションとの連携・相互作用が必然。

しかし、...。
実装技術、データ形式、通信プロトコル。ハードルがやまほどありますね。
見ず知らずの開発チームと共同作業なんていうハードルもある。

概念の不一致


でも、統合の一番の難敵は、それぞれのシステムの「データ」の考え方が違うこと。

ビジネスルールは、いつも変化している。ある時点で造ったアプリケーションとデータは、その時点のビジネスルールの「スナップショット」を反映しているだけ。
社内システムといえども、アプリケーションごと、データベースごとに、異なる考え方を実装したもの。

他社のシステムとの連携ともなれば、根本のビジネスの考え方・決め事がまるで違っているのがあたりまえ。

ビジネスパーソン同士でも、いろいろなすり合わせを行い、契約書や合意書をやまほど積み上げていく。
でも、人同士だと、まだ融通が効く。

エンタープライズアプリケーションという融通の効かないモノ同士の連携は悪夢に近い。
昔のビジネスルール、部分的なビジネスルールを、がちがちに、変更不能な状態に組み込んでしまった「ソフトウェア」(どこが柔らかいんだ!)。

ビジネスロジック


これは、パラドックスです。

ビジネスロジックとは、ロジカルではない。

関係者があつまれば、だいたいの約束事は把握できるけど、緻密に、論理的にくみ立てられたものではない。
ヒアリングすれば、誰も説明できないルールがでてくるのは、みなさんご存知の通りです。

唯一の真実は、「ビジネスロジックは変更される」こと。

どんなにがんばって、その時点でなんとか整理したビジネスルールを実装しても、それは、たんなるスナップショットであり、ある一面のビューにすぎない。

実装してテストしている間に、業務の現場では、別のルールがいつのまにか常識になりつつある。

だから、どうする


格闘すべきテーマは、単純といえば単純。

最初に書いたように、
  • 複雑なデータに対処する
  • (論理的とはいいがたい)変化し続けるビジネスルール


この2点を効果的に実装する、実践的な技術、良い実践ノウハウ。これが、エンタープライズアプリケーションを造るエンジニアのもっとも重要な関心事であり、スキル。

PoEAA 関心事の分離の戦略

マーチンファウラーの PoEAA ( Petterns of Enterprise Application Architecture ) の関心事の分離の戦略。
戦略というか、分離の定石かな?

レイヤ

最初の戦略兵器は「レイヤ」パターン。
これはお約束ですね。

Eric Evans の ドメイン駆動設計 ( DDD : Domain-Driven Design ) でも、まず、ドメインとそれ以外の関心事の分離の基本や「レイヤ」から。

ドメイン層

関心事の中心は、ドメイン層。ドメイン層から出発する。ドメイン駆動ですね。

ドメイン層の中で、さらに関心事を分離するパターンは、Evans の DDD が必読。

 ビジネスパターンによるモデル駆動設計 や「アナリシスパターン」もビジネスの関心事を分離するパターンカタログとして、参考になりますね。

データソース層

次に進むのは、データソース層の課題。

ファウラーの PoEAA では、永続化、それも、リレーショナルデータベースとオブジェクトとのマッピング ( O-R マッピング ) にフォーカスしている。

ファウラー自身が PoEAA の「まえがき」で書いているように、アプリケーション連携、特に、メッセージングによる連携が、永続化とならぶ、重要な関心事。

メッセージングとアプリケーション連携のパターンカタログとしては、
EIP : Enterprise Integration Pattern
が参考になります。

データソース層のアーキテクチャパターンの実装は、オープンソースのフレームワークがいろいろ使える。

Webプレゼンテーション層

次の重要課題は、ユーザインタフェース、特にWebアプリケーションのプレゼンテーションの課題。
利用者から見たら、プレゼンテーション層だけが、ソフトウェアシステムの実体。

プレゼンテーション層のパターンの実装も、フレームワークとか、ライブラリがありますね。
データソース層に比べると、構造や振舞が、ぎこちないものが多く、未成熟な分野かな?

その他の関心事

PoEAA ではパターン化されていない主な関心事は、

・セキュリティ
・バリデーション
・エラー処理
・リッチクライアント
・クラスタリング
...

まあ、ここらへんは、自作することも多いし、Spring フレームワークや、オープンソースのライブラリが利用できる。(実際に動くパターンとして使える)

ドメイン駆動

基本は、ドメイン層中心。
他の関心事も、ドメインの概念や要求を中心に、設計、実装、検証をしていく。

結果的に、ドメイン以外のレイヤにも、ドメインの概念(用語)がたくさん登場する。
ユビキタス言語です。

アプリケーションのアーキテクチャ全体が、ドメイン駆動で、ユビキタス言語。

関心事は、エンタープライズアプリケーション

ソフトウェアといっても、分野は広い。
私の専門は、エンタープライズアプリケーション。

マーチンファウラーの、PoEAA( エンタープライズ・アプリケーション・アーキテクチャ・パターン)の「はじめに」を参考に、エンタープライズアプリケーションの関心事を整理すると...

永続データ

ビジネスでは、データの記録が基本ですね。
過去の事実はもちろん。
もっと重要なのは、将来の約束(予定や契約)を記録して、確実に履行することがビジネスの基本。

たくさんのデータ

ビジネスとは、ビジー(忙しい)ということ。
日々刻々データが発生します。
これを効果的に扱うには?

同時にデータアクセス

ビジネス活動で使う情報やデータは、多くのユーザが同時にアクセスする。
二人のユーザが同時に同じデータで作業する場合はどうなる?
百人、千人が同時に利用するか?もし、そうなったら、どうなる?

多くのユーザインタフェース画面

いろいろなデータ、情報を、いろいろなタイプのユーザが利用する。
何百もの異なる画面が必要。

※画面だけでなく、バッチ処理も忘れてはいけない。

他のエンタープライズアプリケーションとの連携 ( EAI )

ビジネス活動が、さまざまな活動が相互に関連している。
エンタープライズアプリケーションも、孤立して存在することはない。
エンタープライズアプリケーション間の連携が重要な関心事。

アプリケーション間の連携:多様な技術要素

データ形式、通信方式、実装技術、基盤のOSやハードウェア、...
ありとあらゆる技術要素が、混乱を拡大する。

アプリケーション間の連携の課題:概念の不一致

技術的には連携を確保できても...
「顧客」の定義が部門間や、ビジネスパートナー間で異なるのがあたりまえ。
「商品」や「在庫」、「計上ルール」、「例外の扱い」....
エンタープライズアプリケーションの連携の中核の課題は、この概念の不一致をどう扱うか?

ビジネスロジック

ビジネスの決め事は、とっても、論理的「ではない」。
唯一の真実は、ビジネスのロジック(決め事)は、時とともに、場面によって、いつも変化する、ということ。
この変化への対応の方針と手段は?_

大規模システム

ビックビジネスでは、システムも大規模になる。
(もっとも、大きくすることが最善かどうかは別問題。ビジネスもシステムも、自律的に活動するユニットの緩やかな連携が、良いことも多い)

小規模なシステムの累積効果

ひとつひとつのエンタープライズアプリケーションは、小規模では、ビジネス活動全体では、それが集まって、連携して、さまざまな価値を生んだり、逆に、ビジネスの障害になる。

小さいなエンタープライズアプリケーションの質を地道に改善する。その累積の効果は、ビジネスにとって、大きな影響がある。

ずさんな小さなソフトウェア開発プロジェクトの(マイナスの)累積結果に苦しんでいるのが、多くの現場の実態ですね。

calendar
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< May 2018 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM