アリの姉妹REVIEW：著者張Jianfeiアリババ上級技術専門家、6年間の部門は、彼がCOLAを作成しました。紙に優れたものではなく、コピーすることができる実用的なアプリケーションアーキテクチャの仕様のセットを探索することを望んで、それは、床を理解することができる、あなたは指導や拘束の複雑さを制御することができます。COLAの彼のアップグレードの繰り返しを詳述この記事。
多くの学生以上、私はフィードバックを持っていたら、私たちのシステムは非常に主に、混乱です。
-
アプリケーション階層の混乱：DOは適用する方法を知っていないが、階層的である必要があり、どのようなコンポーネント間の関係を含めるべきか、構成要素です。
-
どのような名前がより適切でなければならないから、何の（どのクラス、どのパッケージを）知っていないいくつかの新しいビジネス・ロジックを追加する：標準化ガイドラインと制約の欠如？
-私は早く心COLA（https://github.com/alibaba/COLA）の1を作成どのようなこれらの問題、解決するために、紙の上で優れていない実用的なアプリケーションアーキテクチャの仕様のセットを探索する試みを、しかし、コピーすることができます、それは理解できる、床は、あなたが指導し、拘束の複雑さを制御することができます。
COLAが生まれたので、私はコメントや提案をたくさん受けました。それと同時に、私自身実際には、また、いくつかの冗長設計が必要ではないが、いくつかの重要な要素を含んでいない、COLA 1.0多くの欠陥を発見しました。例えば、私は最近、複雑なビジネスアプリケーションアーキテクチャのコアを考えていたとガバナンスのコードは、COLA 1.0の反射です。
治療の複雑さに実践し、継続的な反射の組み合わせを探検、私はそうは現在COLA 2.0で、包括的なアップグレードCOLAを実施することを決定しました。
1.0から2.0に、簡単な変更は数字だけではなく、また、建築、デザインのコンセプトをアップグレードするために、主なポイントの変更は、次のとおりです。
-
新しい階層化アーキテクチャ：ドメイン層は、もはやインフラストラクチャ層に直接依存しています。
-
新しいコンポーネント部門：コンポーネントを再定義し、部門は、いくつかの古い部品（バリデータ、コンバータなど）に加えて、新しいコンポーネントを追加しました。
-
新しい拡張ポイントの設計：新しい概念の導入は、そのための拡張は、より柔軟です。
-
新たな第2のパーティのライブラリポジショニング：第二パーティのライブラリだけDTOは、軽量表現と実現のドメインモデルです。
新しい階層化アーキテクチャ
COLA 1.0では、我々は古典的な層状の階層構造の下に示します：
COLA 2.0、またはこれらのレベルが、依存関係の変化を、ドメイン層は、もはやインフラストラクチャ層に直接依存しないが、DIP（依存性逆転原理、依存反転）反転層およびドメインを使用してゲートウェイの概念を導入しますインフラ依存層、下に示すような関係：
これの利点は、ドメイン層は、単にビジネスロジックに対処するための心の平和のように、技術的な詳細（だけでなく、複雑さをもたらす技術的な詳細）への依存から完全に自由に、より純粋になりますです。
また、2つの利点があります。
1.並行開発：限り、インターフェースは、ドメインとインフラ間の良好な一致であるように、2人の学生は、並列コードドメインおよびインフラストラクチャを記述する必要があります。
2.テスト容易性：依存POJOクラスですノードメイン、テストユニットは、TDDの開発のために非常に適した、非常に便利になります。
新しいコンポーネント部門
そして、コンポーネント定義モジュール
まずは、部品（コンポーネント）の概念の定義について明確にしましょう、Javaでコンポーネント（または、この記事では）、その範囲は、Javaパッケージ（パッケージ）です。
モジュール（モジュール）と呼ばれる言葉がありますが、コンポーネントおよびモジュールこれら二つの概念は混同しやすいです。たとえば、「実装ドメイン駆動設計」で、著者は言います：
あなたはJavaやC＃を使用している場合は、別の名前で彼らを知っているのに、あなたは、すでにモジュールに精通しています。Javaは、それらのパッケージを呼び出します。C＃は、彼らが名前空間を呼び出します。
彼は、モジュールパッケージが、私はこの定義が混乱していると思うと信じられています。特に、Mavenを使用して、とMavenでは、モジュールがアーティファクト、パッケージの代わりに通常の瓶であるとき。例えば、それは4 COLA Frameworkのモジュールを含みます：
<モジュール>
<モジュール>コーラ-共通</モジュール>
<モジュール>コーラコア</モジュール>
<モジュール>コーラ-拡張</モジュール>
<モジュール>コーラテスト</モジュール>
</モジュール>
確かに、モジュールおよびコンポーネントこれら二つの概念が似ている、それが原因の混乱に思われます。たとえば、StackOverflowの[1]上の問題があり、モジュールとコンポーネントの違いを依頼することです。答えは範囲によって区別最高の賞賛を得ることです。
用語が似ています。私は一般的に、「コンポーネント」よりも大きなものとして、「モジュール」を考えます。コンポーネントは、スコープ内に通常、比較的小さい単一の部品です。
答えは、私の腸の反応は、モジュールのコンポーネントよりも大きくなっていること、同じです。上記の情報に基づいて、私はいくつかの定義コンポーネントモジュールを行うためにここにいるとここに記載さ、以下の定義及び表記（表記）に準拠しています。
-
モジュール（モジュール）：とMavenモジュールジャーを理解するために一貫性のある、シンプルで定義されています。彼は、キューブを表明しました。
-
コンポーネント（部品）：とUMLには、同様のパッケージを理解することは簡単で、定義されました。図のUMLコンポーネントによって表されます。
A Moudleは、通常、複数の成分からなる、および関係表記は次の通り：
COLA 2.0コンポーネント
COLA 2.0で、我々はいくつかの新しいコンポーネントを紹介するだけでなく、削除、一部の古いコンポーネントに、コンポーネントを再設計しました。これらの変更の目的は、より良い開発の指針と拘束を提供するために、より明確にアプリケーションをより明確な構造、責任の部品を作ることです。
下に示すような新しいコンポーネント構造。
これらのコンポーネントは、各責任の独自の領域を持っているが、責任は私たちの上に言うことですCOLAの重要な構成部分である「指導と拘束。」これらの構成要素の詳細な機能については後述します。
-
セカンドパーティのライブラリコンポーネント：
-
API：インタフェースは、外部アプリケーションに格納されます。
-
dto.domainmodel：軽量オブジェクトのフィールドにデータを送信するために使用。
-
dto.domainevent：フィールドイベントデータ伝送のために使用されます。
-
-
コンポーネントでのアプリケーション：
-
サービス：ファサード・インターフェースの実装、無ビジネスロジックは、別のターミナルアダプタを含むことができます。
-
EventHandlerの：このドメインおよび細胞外ドメインを含む、芸術イベントを処理します。
-
エグゼキュータ：処理命令（コマンド）と複雑なビジネスへの問い合わせ（クエリ）、およびのためには、位相ステップを含むことができます。
-
インターセプタ：COLAが提供するすべての要求を処理するためのAOPメカニズム。
-
-
ドメインどこコンポーネント：
-
ドメイン：ドメインモデル継承を許可するドメインエンティティ、。
-
DomainService：フィールドサービス、より粗い粒度を提供するために、フィールドの能力。
-
ゲートウェイ：ストレージ、RPC、検索などを含む外部依存インターフェイスゲートウェイ。
-
-
コンポーネントでのインフラストラクチャ：
-
設定：設定情報に関連します。
-
メッセージ：メッセージ処理に関連します。
-
リポジトリ：ストレージ関連、専門ゲートウェイは、主に現フィールドデータのCRUD操作のために使用されます。
-
ゲートウェイ：の（ゲートウェイ内ドメイン）の外部依存ゲートウェイインタフェースの実現。
-
COLAを使用する場合は、我々のアプリケーションの制約を構築するために標準化されたコンポーネントを追跡してみてください。これが私たちのアプリケーションフォローする明確な構造を可能にします。それは行くので、コードの保守性と分かりやすさが大幅に改善されます。
新しい拡張ポイントのデザイン
新しい概念の導入
ビジネス、ユースケース、シナリオ：議論の前に、のは、新しいコンセプトはCOLA2.0拡張設計に導入されたものを定義してみましょう。
-
ビジネス（ビジネス）：小売り、などtmallとして、資金調達本体の自己資金で、淘宝網は、3つの異なる事業を通じてです。
-
実施例（ユースケース）と：ユーザおよび1つまたは複数のユースケースシナリオを提供その各々のシステムとの間の相互作用を記載します。例えば、支払命令は、典型的なユースケースです。
-
シナリオ（シナリオ）：シナリオも使用事例（インスタンス）のインスタンスと呼ばれ、それはすべての可能なケースが（正常および異常）実施例含みます。たとえば、「注文賃金への」ユースケースのために、バランスアリペイの欠如、「と他の多くの場面「の銀行口座の残高が不足」」そこ「聖歌を過ごすために使用することができます」。
簡単に言えば、ビジネスユースケースの複数の実施形態で複数のシーンで構成されて構成されています。次のような関係で使用淘宝網、ビジネスユースケースとシナリオを作るための簡単な例：
新しい拡張ポイントを実装
COLA 2.0において、拡張メカニズムの実装に変化は、主な変更は、新しい概念が上で導入することをしません。オリジナルの展開の大きさも、「ビジネスアイデンティティ」スターリングをコピーするようCOLAので、設計1.0つ星リングから延びます。以下に示す拡張位置1.0 COLAの方法：
しかし、実際には、スターリングとしては珍しくとして複数のビジネスシナリオをサポートすることができます。より多くのサポートは、例、または右を使用していない別のユースケースのシナリオで区別されます。たとえば、「製品の作成」と「製品のアップデート」は、2つのユースケースが、ビジネスのコードのほとんどは再利用することができ、かつ分化治療の必要性のほんの一部です。
このよりきめ細かい拡張サポートをサポートするために、以前の「ビジネスアイデンティティ（BizId）」に加えて、私はまた、ユースケースシナリオ及びこれら二つの概念を導入しました。以下のように新しい拡張機能を配置します：
それは、元のが唯一の拡張の「ビジネスのアイデンティティ」をサポートすることができ、新しい拡張フレームワークで見ることができ、今、「ビジネスのアイデンティティ」、「ケース」、「シーン」3つの拡張機能をサポートし、間違いなく以前よりも柔軟になりますそしてより多くの、また、以前よりも良いと理解しやすいの表現インチ
新しい拡張フレームワークの下では、そのような私たち上の画像のようにショーの拡大を達成：このビジネスtmallを - シングルユースケースを - 88VIPシーンの - ユーザID認証を展開する、我々は次のいずれかを宣言する必要がありますその上に拡張機能の実装（拡張子）。
新たな第2のパーティのライブラリポジショニング
位置決めライブラリビューの両側面について、それは、簡単な問題であり、以下のインタフェースとデータ転送（DTO）を露出するよりも、何もない2つのパーティのライブラリとサービスので。それは異なる境界コンテキスト（有界コンテキスト）間の調整の問題に関連するしかし、深い思考に、それは、簡単な質問ではありません。 それはコラボレーションの間で分散環境、異なるサービス（SOA、RPC、マイクロサービス、異なる名前、異なる性質）アーキテクチャがいかに重要であるかの質問です。
有界コンテキスト間のコラボレーション
どのようにも、それぞれの分野における概念の整合性を確保しながら、異なるドメイン間でのコラボレーションを有効にするにはセット方法論です。全体的に、二つの方法は、おそらくあります（共有カーネル）カーネルを共有し、（ACL、腐敗防止Layer）をコーティングします。
1.共有カーネル（共有カーネル）
それはチームの一つだけが共有されている何のためのコード、ビルド、およびテストを維持することが可能です。あなたがチームと共有するためにモデルを構成するもので一定の合意とのオープンなコミュニケーションを持っていなければならないので、Aの共有カーネルは、多くの場合、非常に最初の場所で想像することは困難で、かつ維持することは困難です。
上記は、「DDD蒸留」への言及である（著者はヴォーンバーノンである）共有カーネル上の元の単語は、利点シェアを記載（重複を減らす）、その欠点は、共有（チームとの間の密結合）です。
2.コーティング（ACL、腐敗防止層）
アン汚職防止層は、下流のチームはユビキタス言語（モデル）と、それに上流にあるユビキタス言語（モデル）との間の変換層を作成し、最も守備のコンテキストマッピング関係、です。
最も徹底的なコーティング手法を単離するためにも「DDD蒸留」から、ある全く欠点シェア（特定の変換コスト）であるノーシェア（完全デカップリング、それぞれ独立して）、という利点を有します。
しかし、私の視点とほとんどバーノンは、それ以上の抗腐食層の練習を支持しています。そのため、システムの保守性とわかりやすさに比べセマンティック変換陳の増加、の、それは完全に価値があります。
可能な限り、あなたは、特にあなたのビジネスニーズに合わせて、その完全に外国の概念から分離されたあなたを保つこと統合のあなたの側にモデルのコンセプトを作り出すことができるように、あなたの下流モデルと上流の統合モデルの間で汚職防止レイヤーを作成してみてください。
第二パーティのライブラリを再配置
ほとんどの場合、ライブラリーは確かにある双方向サービスには、インタフェースおよびデータ・プロトコルを定義するために使用されます。しかし、それは単なるプロトコルではありませんJSONライブラリーとは異なる第二当事者は、それがJavaオブジェクト、ジャーパッケージです。
それはJavaオブジェクトであるので、それは我々がDTOは、ゲッターに加えてのセッターをより多くの機能を運ぶ作ることを意味します。この問題は、前に私の注意を引き起こすことはありませんでしたが、思考の最近の時間領域モデルでは、私たちは大きな役割を果たしているために、より多くの責任を取るために、2つのパーティのライブラリを作ることができることを見出しました。
実際には、アリは、私はすでに、このようなAの実際にいくつかのチームは、と私は結果はかなり良かったと思うことがわかりました。例えば、カテゴリテーブル二パーティのライブラリで、この問題でより良いデモンストレーションを行います。商品カテゴリは、計算の多くが含まれ、より複雑なロジックであり、我々は、コードカテゴリ二パーティのライブラリを見て書く方法です。
上記のコードから、私たちはこれをはるかにDTOの範囲を超えてしまったことが確認でき、これはドメインモデルである（データ、行動、継承を持っています）。そうする権利？私はそれが適切だと思います。
-
まず、使用DefaultStdCategoryDOすべてのデータは、外部の支援の助けを借りずにこれらの計算は、自分自身が完了していること、自己矛盾しています。例えば、カテゴリのパス名を取得し、それは葉のカテゴリであるかどうか、それはルートカテゴリであるかどうかを判断するために、彼らが完了するために、自分自身です。
-
第二に、これは、共有カーネルは私が判断を下すためにisRoot（）を使用する必要が100個のアプリケーションは、あなたが実装する必要はありませんがある場合は、ライブラリにさらさ双方向を通じて知識（言語、データおよび行動）の分野で自分自身を置く、あります。
何？カーネルにそれを共有するのはお勧めということを意味しませんか？（まあ、子供Caifenの正しいか間違っている、してください）。ここでは、カーネルの共有、私は肯定的である、と考える重いコンピューティングの光、シーンというデータの特定のカテゴリ。しかし、密結合によって引き起こさシェアは確かに問題です。私はサービスの消費者のカテゴリだのであれば、私は両方の能力の領域でそれを再利用することができ、また、腐食の分離で役割を果たすことができるように、ラッパー包装カテゴリー多重化して行くことを選ぶだろう。
2・パーティのライブラリでCOLA
それを言って、私は2番目のパーティのライブラリへの私の態度を理解するために持ってすべきだと思います。はい、2つの当事者はちょうどインタフェースライブラリとDTOが、フィールドの重要な一部であるべきではない、共有カーネルを達成するための重要な手段です。
したがって、私はCOLA 2.0における第二パーティのライブラリの責任の範囲を拡大していきます。主なポイントは以下のとおりです。
-
第二者ドメインモデルライブラリはまた、フィールド発現する能力で「軽量」、「軽量」、いわゆるフィールドの重要な一部である自己表現がに似て適切かつ十分な凝集、あるある上記StdCategoryDOは言いケース。もちろん、スキルも共通言語（ユビキタス言語）に追従する必要があります。
-
別の有界コンテキスト間のコラボレーションは、ブリッジの良い二パーティのライブラリをフルに活用します。協働する方法を以下に示します。
これは単なる提案ではなく、標準であることに注意してください。実際には、我々は常にトレードオフの共有とカップリングとの間には、アーキテクチャのない完璧な世界が存在しないことを確認する必要があり、完璧なデザインがありません。 それはあなた自身が決める実際の場面を所有する必要があり、フィット。
拡張メカニズムのCOLAフレームワーク
これまでのところ、変更点COLA 2.0私はほとんど同じことを告白しています。その後、卵とAPPEND Aバー。サポートが拡張する方法のためのフレームワークとしてCOLA（フレームワーク）についてリーク。
フレームワークの構成要素は、このようなロギングフレームワークのlogbackとして、システム内の特定のタスクを完了するために統合することがあるので、私たちは、印刷ログ、ログフォーマット、ログ保存やその他の問題の解決を支援することです。しかし、アプリケーションのさまざまなシナリオに直面して、フレームワーク自体は、あなたが、ログフォーマットを望むようにアーカイブログものを予測する方法はありません。これらの場所は拡大して、自分自身を設定するには、ユーザーを有効にする、拡張メカニズムを必要としています。
実装に拡張するために、2つの方法があり、一つは拡張インターフェースに基づいており、拡張されたものがコンフィギュレーションデータに基づいています。
ベースの拡張インターフェイス
拡張インターフェースに基づいて、ユーザが自分のカスタムを達成するために、インタフェースと処理テンプレートを定義するためのフレームワークにおけるオブジェクト指向の多型機構、インターフェース（または抽象メソッド）の使用です。以下に示すような原理は次のとおりです。
この使用は、例えば、ユーザが初期化容器行うリスナー後にこの特別な処理を達成することができるApplicationListener春のフレームで広く拡張方法です。logback AppenderBaseの別の例は、ユーザーがアペンダを継承AppenderBaseによって（ログメッセージキューを送信するために）要求をカスタマイズすることができます。
COLAは、フレームワークとして、スケーラビリティが避けられないので、例えば、私たちはExceptionHandlerIを持って、我々は、デフォルトの実装を提供する枠組みの中で、次のように：
しかし、誰もがこのような構成を適用するために喜んで、私たちは、ユーザーがユーザーが提供されていない場合は、ユーザーを実装し、優先度の彼のExceptionHandlerI実現、デフォルトの実装を提供する場合、延長ます：
拡張データの設定に基づいて、
第1のデータフォーマットに一致するように、拡張されたコンフィギュレーションデータに基づいて、次にオブジェクト・インスタンスに組み込まユーザが入力したデータを用いて、ユーザによって提供されるデータは、オブジェクト属性が（時々StaticLoggerBinder例示的slfjために、基づいていてもよい）されます以下に示すような原理は次のとおりです。
アプリケーションで使用される我々一般的に配置されたKVはフレームを使用して、この形態のものであるような上記logbackログ形式、ログサイズlogback.xml構成など多くのシナリオです。
COLAにおいて、我々は@Extension配置注釈ポイント拡張（bizId =「tmall」を、ユースケース=「placeOrder」、シナリオ=「88vip」）は、典型的な拡張コンフィギュレーションデータに基づいています。
COLA 2.0の使い方
ソース
COLA 2.0ソースコードhttps://github.com/alibaba/COLA
COLAのアプリケーション生成
COLA 2.0アーキタイプの二組、純粋なバックエンド・アプリケーション、他のAのバックエンドのWebアプリケーションを提供し、それらの間の差は、バックエンド・アプリケーションのWebアプリケーションであり、より純粋なバックエンドコントローラモジュールよりも、他は同じです。私はMavenのレポ、COLAアプリケーションにアップロードした原型の二パーティのライブラリは、以下のコマンドで生成することができます：
生成純粋なバックエンド・アプリケーション（NOコントローラ）
mvnarchetype:generate -DgroupId=com.alibaba.demo -DartifactId=demo -Dversion=1.0.0-SNAPSHOT-Dpackage=com.alibaba.demo-DarchetypeArtifactId=cola-framework-archetype-service-DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=2.1.0-SNAPSHOT
生成バックエンドのWebアプリケーション（そこコントローラ）
mvn archetype:generate -DgroupId=com.alibaba.demo -DartifactId=demo-Dversion=1.0.0-SNAPSHOT -Dpackage=com.alibaba.demo-DarchetypeArtifactId=cola-framework-archetype-web-DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=2.1.0-SNAPSHOT
私たちは、デモと呼ばれる新しいアプリケーションは、次のモジュール構造を参照して、コマンドを実行した後、アプリケーションは骨格の一部であり、フレームの下部はCOLAであることを前提としています。
いくつかのデモ生成されたコードを有するアプリケーションで直接「MVN試験」を用いて試験することができます。// localhostを:? 8080 /顧客名=アリババ・アクセス・サービス：REST URLのhttp経由で直接、その後TestApplication開始春ブーツコンテナを実行して、できるバックエンドのWebアプリケーションの場合。
COLA 2.0全体的なアーキテクチャ
最後に、古いルールに従って、またはアーキテクチャの二つのグローバルビューに。だから、COLAから全体の状況を把握することができます。
注：COLAは二つの意味、COLAの枠組みとして1つの意味、共通のアセンブリをサポートするために必要な主にいくつかのアプリケーションを持っています。別の意味は、COLAアーキテクチャは、アプリケーションスケルトンフレームワークによって生成されたアーキタイプCOLAを指す指します。ここでのアーキテクチャは、アプリケーションアーキテクチャビューの図です。
従属ビュー
ビューを呼び出し
参考文献：
【1】
https://softwareengineering.stackexchange.com/questions/178927/is-there-a-difference-between-a-component-and-a-module?spm=ata.13261165.0.0.12296659zlPIXl
記事から：アリ・テクノロジー
