タグ付けされた質問 「modularization」

5
別のマイクロサービスによって「所有」されているデータベースからデータを読み取ることがなぜそれほど悪いのか
最近、マイクロサービスアーキテクチャに関する次の優れた記事を読みました。http://www.infoq.com/articles/microservices-intro AmazonにWebページをロードすると、100以上のマイクロサービスが協力してそのページを提供することが記載されています。 その記事では、マイクロサービス間のすべての通信はAPIを介してのみ行うことができると説明しています。私の質問は、すべてのデータベースの書き込みはAPIを介してのみ可能であると言うのがなぜ悪いのかということですが、さまざまなマイクロサービスのデータベースから直接読み取ることができます。たとえば、マイクロサービスの外部からアクセスできるデータベースビューはごくわずかであるため、マイクロサービスを管理するチームは、これらのビューをそのまま保持している限り、マイクロサービスのデータベース構造を変更できることを知ることができます。欲しいです。 ここに何かが足りませんか?API経由でのみデータを読み取る必要がある他の理由はありますか? 言うまでもなく、私の会社はAmazonよりもずっと小さく(常にそうです)、私たちが持つことのできるユーザーの最大数は約500万人です。

2
複数の小さなアプリを含む大きなAngular 2アプリを作成する
React(with Redux)とAngular 2を選択するための長い3か月にわたる議論と研究の末、私の会社のフロントエンドチームは、Angular 2を採用することを決定しました(私たちの問題により適しています)。 現在、多くの異なるフロントエンドテクノロジーで構成されているエンタープライズアプリビジネスに取り組んでいます(バックエンド全体をRESTfulにしています)。すべてを置き換えて、将来のトレーニングと品質管理を容易にする単一のテクノロジーが必要でした。 私たちの製品の性質を考えると、それは広大であり、その中には異なるドメインであり、スタンドアロンアプリとして作成できるモジュールがありますが、製品自体は単一のURLに存在します。 例; 私の製品をSuperAppと呼びましょう。 UIとして、SuperAppには標準のログインシステムと、子モジュール/サブ製品へのナビゲーションがあり、ワークフローは次のように表示されます。 SuperApp ユーザーを認証する パスワードを忘れたウィザード 認証なしでアクセスできる公開ページ 認証されたユーザー ナビゲーションシステム ホーム サブ製品1 サブ製品2 サブ製品3 プロフィール ... ... グループ ... ... 上記表現にそのノート、Sub-product1そしてSub-product2全く異なるビジネスドメインを有する、2つの全く異なる領域です。 私が今考えることができるのは、自分自身に関連するコンポーネントとビューのみを持つ単一のAngular 2プロジェクトとしてSuperAppを作成でき、SuperAppは複数の子アプリのロードも担当しているということです。Sub-product1、Sub-product2(自分の有する再び、異なる角度の2つのプロジェクトpackage.json、webpack設定、等)をダムコンポーネントを介して、トップレベルのルーティングを提供するシェルと、これらの子アプリを保持するためのプレースホルダとして機能します。 、いったんSub-product1シェル内にロードされ、それがSuperAppがで上陸したことを現在のルートに、独自のルートを追加します。 分離が必要な理由は、これらのさまざまなアプリ(現在はExtJSを使用して構築されている)が専用のチーム(私たちは500人以上の開発者を抱えている会社です)を持っているためです。グランド親アプリに依存せずに好みに依存します。 しかし、公式のAngularドキュメントやWebでは、ネストされたAngularアプリを持つことができるかどうかはまったくわかりません(子アプリの依存関係が完全に分離されてロードされている間にフレームワークコードが共有される方法で)またはそのような問題を解決するための代替アプローチがあるかどうか。 関連する記事へのガイダンスやリンクも歓迎します。

6
懸念の分離について書いたとき、ダイクストラはコードのモジュール化を意図していましたか?
まず、私は1974年の「科学的思考の役割について」の抜粋エズガーW.ダイクストラの論文を読みました。 私にあなたに説明しようと思います、私の好みに何がすべてのインテリジェントな思考に特徴的です。それは、自分の一貫性を保つために、自分の主題の側面を分離して詳細に研究することをいとわないことです。常に、側面の1つだけで自分を占有していることを知っています。私たちはプログラムが正しい必要があることを知っており、その観点からのみそれを学ぶことができます。また、効率的である必要があることもわかっており、いわば、別の日にその効率を調査することができます。別の気分では、プログラムが望ましいかどうか、またそうである場合、なぜプログラムが望ましいかを自問することがあります。しかし、これらのさまざまな側面に同時に取り組むことによって何も得られません-逆に!-。それは私が時々「懸念の分離」と呼んだものであり、それは完全に可能ではないにしても、私の知る限り、思考を効果的に順序付けるために利用できる唯一の手法です。これは、「ある側面に注目する」という意味です。他の側面を無視することを意味するのではなく、この側面の観点から見れば、他の側面は無関係であることを正当化するだけです。それは1つと複数のトラックを同時に気にしています。 私は、コードをモジュール化することについて、現代の懸念の分離が語られているのを見ています。しかし、上記の引用を読んで、私はこれをあなたの心を一度に1つの特定のタスクに集中させ、他の側面に焦点を合わせないものとして理解します。これは、必ずしもコードをモジュール化されたチャンクに分離する必要があることを意味するわけではありません。 つまり、1つのファイルに、ビュー、リポジトリ、コントローラー、イベント処理、ファクトリーなどの概念がすべて1つのファイルにあるというコードが目の前にあるとします。 簡単な例として、データアクセスと表示(出力)を行うコードを次に示します。 $sql = "SELECT * FROM product WHERE id = " . db_input($id); $row = db_fetch_array(db_query($sql)); <option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? ' selected="selected"' : '' ?>>Version <?=$row['ver']?></option> モダンなオブジェクト指向を使用して、リポジトリパターンを使用して独自のファイルにデータアクセスを配置し、ビューコードを独自のファイルテンプレートに入れ、それらをまとめてコントローラー(またはアクションまたはリクエストハンドラー)を介して通信することができます。ファクトリーを追加して、さまざまな依存関係を作成して接続します。そして、それらのファクトリーを定義する構成ファイルを持つことができます。確かに、それは単一ファイルのすべてから一歩離れています。 懸念の分離に関する私の質問は次のようなものです。ダイクストラの引用を読んで、おそらく彼が懸念の分離を必ずしも「コードのモジュール化(ファイルまたは独自の関数/メソッド/その他への)分離」であるとは限らないという考えを得ました。また、コードで物理的に分離されているかどうかに関係なく、他の重要であるが現時点では検討されていない側面に集中することなく、プログラムの側面に集中することを意味しました。 では、なぜ、物理的なモジュラーコードの分離と設計パターンに負担をかけているのでしょうか。コードがどのように構造化されているかに関係なく、アスペクトに専念するだけでは十分ではありませんか? 私は最も恐ろしいスパゲッティコードを書くことについて話しているのではなく、その側面のみを検討しているので、それはおそらく負担になります。しかし、結局のところ、私が目指しているのは、物理的なコード分離を実行する理由であり、側面に精神的に集中する必要がないのに、なぜコードを個別のファイルまたはチャンク(メソッド)に分割するのか、です。 懸念の分離は、肉体的ではなく精神的な運動のままである必要がありますか? 言い換えれば、プログラミングの精神的側面(焦点を当てる)と物理的側面(紙面上のコード)の間に断絶があるべきでしょうか?

2
ソフトウェアアプリケーションの異なる部分をきれいに分離する方法は?
多くのビジネスロジックを処理する新しいアプリケーションを設計しています。 時間の経過とともにこのようなシステムに潜入することが多い、さまざまなアプリケーションレイヤー間の通常の絡み合いを回避するために、最初から問題の明確な分離を実装したいと思います。大まかに言えば、私は分離したいです: プレゼンテーション層 ビジネスロジックレイヤー データストレージと永続化レイヤー 私が最も苦労しているのは、特にビジネス層とデータ層の間で、実際にエッジで動作をきれいに実装する方法です。データレイヤーがORMオブジェクトをコアレイヤーに渡し、ビジネスロジックをORMに効果的に密結合するアプリケーションが多すぎます。 ORMオブジェクトをシリアル化された形式(JSON?)に変換してから、ビジネスレイヤーでそれを非シリアル化して、そのレイヤー内部のデータ構造にする必要がありますか?それは多くのオーバーヘッドではありませんか? 中規模アプリケーションの懸念の分離をきれいに実装するにはどうすればよいですか?何かアドバイス?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.