技術的な結合度と設計的な結合度 - arclamp
ささっとBlogを書く訓練。 エンタープライズシステムではシステム間を疎結合に保つことが重要とされます。結合度が下がっていれば両者の依存関係は弱くなります。システムAとBがあったとして、Aが停止した場合に、それによってBが停止しない（縮退はするかも）、あるいはAの内部仕様に変更があった場合に、それによってBが仕様変更を強制されることがない、という示しています。 結合度が低ければシステムのライフサイクルをずらすことができるため、運用上も保守上も大きなメリットになります。 とはいえ、結合度が高いことでのメリットもあります。主にはコストの低下や性能の向上が見込めます。 マスタデータを共有したい場合、ファイルによるデータ交換は結合度を下げることができます。ですが、双方がファイルを入出力する仕組みを作る必要があり、かつ、連携遅延が出てしまいます。そうではなくて、直接データベースを共有するようにすれば
エンタープライズ疎結合アプリＭＡＰ
今回は企業内アプリ”全体”を疎結合化した際に、どのような形になるかをご紹介するとともに、そのポイントがどこにあるかについてお話したい。小生、全社システムの絵を描くのは久しぶりである。今後何かに使えるかも知れないので、少し気合いを入れて書いてみたのでご覧いただきたい。 既にバックナンバー”2015.4.6“で、ER図を用いて疎結合化の勘所を説明したが、今一つ具体例が足りないという読者のために、局所的な例ではなく全社システムのいたる所に疎結合化を施したエンタープライズモデルを作成してみた。 ご紹介するモデルは架空の企業（業種はメーカー）であるが、各アプリケーションに登場するエンティティは定石通りに描いたつもりである。各アプリは独立して機能し、それらが緩やかにシンクロナイズしながら、全体で整合性を保って機能する自立分散型システムとなっている。 読者の方は既にお気付きと思われるが、同じ名前のエンテ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
