タグ

masterに関するmoronbeeのブックマーク (4)

  • 【上級】変化に強い情報システムを作る 第2回(後半) アプリケーション・ポートフォリオほか | 日経 xTECH(クロステック)

    概念データモデル作成と並行して,アプリケーション・ポートフォリオを策定する。アプリケーション・ポートフォリオは,サブシステムの目的と役割を明確にし,サブシステムの独立性が高い構造を実現するために作る。 アプリケーション・ポートフォリオは,企業情報システムの構造をトップレベルで表したものである。企業が扱う情報の特性,役割などを分類し,それらの関連を示す。さらに情報システムの構成要素であるアプリケーションの特性も記述する。これによって,分類された各系は互いにどう関連するかが明確になり,次のアプリケーション・アーキテクチャ策定への指針となる。企業を新たに作るときに組織の構成を考えるように,システム全体に必要な要素をゼロからトップダウンで考えて作る。 例えば,次のようなサブスシステムを定める(図4[拡大表示])。 ・中核業務用データベースを維持管理するサブシステム(基幹業務系) ・業務フローや画面

    【上級】変化に強い情報システムを作る 第2回(後半) アプリケーション・ポートフォリオほか | 日経 xTECH(クロステック)
  • 技術的な結合度と設計的な結合度 - arclamp

    ささっとBlogを書く訓練。 エンタープライズシステムではシステム間を疎結合に保つことが重要とされます。結合度が下がっていれば両者の依存関係は弱くなります。システムAとBがあったとして、Aが停止した場合に、それによってBが停止しない(縮退はするかも)、あるいはAの内部仕様に変更があった場合に、それによってBが仕様変更を強制されることがない、という示しています。 結合度が低ければシステムのライフサイクルをずらすことができるため、運用上も保守上も大きなメリットになります。 とはいえ、結合度が高いことでのメリットもあります。主にはコストの低下や性能の向上が見込めます。 マスタデータを共有したい場合、ファイルによるデータ交換は結合度を下げることができます。ですが、双方がファイルを入出力する仕組みを作る必要があり、かつ、連携遅延が出てしまいます。そうではなくて、直接データベースを共有するようにすれば

    技術的な結合度と設計的な結合度 - arclamp
  • エンタープライズ疎結合アプリMAP

    今回は企業内アプリ”全体”を疎結合化した際に、どのような形になるかをご紹介するとともに、そのポイントがどこにあるかについてお話したい。小生、全社システムの絵を描くのは久しぶりである。今後何かに使えるかも知れないので、少し気合いを入れて書いてみたのでご覧いただきたい。 既にバックナンバー”2015.4.6“で、ER図を用いて疎結合化の勘所を説明したが、今一つ具体例が足りないという読者のために、局所的な例ではなく全社システムのいたる所に疎結合化を施したエンタープライズモデルを作成してみた。 ご紹介するモデルは架空の企業(業種はメーカー)であるが、各アプリケーションに登場するエンティティは定石通りに描いたつもりである。各アプリは独立して機能し、それらが緩やかにシンクロナイズしながら、全体で整合性を保って機能する自立分散型システムとなっている。 読者の方は既にお気付きと思われるが、同じ名前のエンテ

    エンタープライズ疎結合アプリMAP
  • 継続的インテグレーションは死んだ | To Be Decided

    このエントリでは、Yegor Bugayenkoによる記事、Continuous Integration is Deadを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 数日前、「なぜ継続的インテグレーションは機能しないのか」という私の記事がDevOps.comに公開された。 それとほぼ同じ日に、Twitterで非常に否定的な批評が送られてきた。 継続的インテグレーションが機能しないとはどういうことだ。この人気なすばらしいアイデアが。 その求めてもない質問への返事をここに書く。 私はこの分野に関して多少の経験があるが、それに基いた論拠は挙げない。 代わりにロジックだけを頼りにする。 ところで、私には50以上のオープンソースや営利プロジェクトで5年間Apac

  • 1