概要
マイクロサービスのためのDDDのアイデアを通じてモノマーサービス内のプロジェクト構造を調整する方法についての記事の前には準備を分割します。踏まときにも説明したが、当社のマイクロスプリット中のいくつかのピットサービスです。
私たちの最終案には、この導入の下では、必ずしもメッセージを議論する歓迎。
マイクロサービス部門
分析
当社のサービスの一部は、最初の分類のための基準を導入しました
- 定期的なサービスの一つの領域分割するには、
- 一方、フィールドの純度を確保するために、我々は区別フィールドサービス、フロントデスク。サービス部門は、ロジックの分野で直接フロントにさらされていません。フロントデスクは、フロントにさらされる様々なサービスエリアを、組み立てます。
- 同時に、拡張性を維持するために、我々はマイクロインキュベーターとしてのサービスを予約します。、（新規事業の例えば、最も）の地域については明確ではないサービスハッチの内部に配置され、そして再び分割するのに十分な大きさ他の領域。
より顕著に典型的ないくつかの練習問題の後
- サービスホット問題は、
我々は反復を行くことができないかわからない、ビジネスの反復の過程で、新たな需要分野のほとんどは明確ではない、新たなビジネスです。そのため、コードを書くために成長を提供するためにある、以前の基準に従って、これは、このプロジェクトの開発でチーム内のほぼすべての人につながっている、我々はマイクロスプリットサービスの意味を失いました。
- サービスがあまりにも深刻な依存している
PCがある場合、すべてのニーズを書く事を、私たちはより多くのアプリケーションを記述する必要がある、フィールドサービス、フロントデスク、PCサービスは、モバイルでの開発にサービスを提供するために、表示するために、モバイル端末上で開発する必要があります。サービス間の通話は、人々の開発は、多くの場合、問題に応じて、バージョンを混同している間ので、あなたは、脂肪のバージョンを必要とする、RPCクライアント・インタフェースを記述する必要があります。ライン上のサービスも頭痛、小さな変更の要件、複数のサービスを展開する必要があります。マイクロサービスは、非常に重要なポイントは、デカップリングが独立して展開することができるということです。明らかに非常に適切ではないマイクロなどのマルチレイヤUIサービス層。
- パーティショニングの問題領域
サービスの分野では、粒径が小さすぎると、いくつかのものは、このような顧客サービス、フィールド上やブログ、それの上に置かれ、ユーザの好みのブログ、として、内側にどのサービスかわかりません。
3つの一般的な問題より顕著な問題、反応があります
サービスの境界は明確ではありません
マイクロボーダーサービスは明らかではない、原因は確かに十分に正確な標準的な定義ではありません
間のサービスへの依存度
依存サービスがより多くの、そして我々はマイクロサービスのメリットを享受することはできませんが、唯一の悪いマイクロサービスを感じることができるかどうかの重要な特徴は、マイクロサービス自律です。
解決アプローチ
この問題を解決するために、我々はグループ内での綿密な協議を行った分類のための私達の基準に反映させます。一貫性は、私たちは深い思考の不在で、時期尚早マイクロサービスが大きな領域を分割し、DDDを実装する必要があるため、それがあると思います。それは多くの問題につながりました。状況ではそうしながら、それが最善の解決策ですが、問題は非常に顕著に起因しています。マイクロスプリットにサービスを提供するための最良の時間は、それが実行されたときにそれ？
理論、認知常に終わり、本当の知識の唯一の実践を学んでいるので。私たちは、過去の過ちにもつれたが、DDD理論を再読み込みしません。この時間は異なると考えなければなりません。
戦略的なデザインのDDD、有界コンテキストを見つけるためにフィールドを分割するには、コアドメインを識別する。次に戦術的な設計、モデリングの分野がある
集約ルート、エンティティ、値オブジェクト、フィールドサービス、フィールドイベント。戦略的なデザインは、通常、遊びの指導思想、戦術設計された特定のスタイルです。私たちは、識別され始め
、その後プレーの特定のスタイルがあり、イデオロギーを導く、最初。今、私たちが間違った、指導思想は容易ではない、またそれは同じではありません。初めに基準が定められていないそれは実際のゲームから来なければなりません。
同時に、我々は常にガイドラインを改訂し、改善、実際に総括する必要があります。
だから我々は再び、再び事業全体をとかします
フロントオフィス機能
すべての私達の機能のフロントエンドは再びそれをとかしている、塗装マップ
ビジネス・アーキテクチャパノラマ
フロントオフィス機能、さらに統合によると、抽象ビジネスパノラマアーキテクチャ
文脈に分け
ビジネス・アーキテクチャパノラマによると、有界コンテキスト、マイクロスプリットコアドメインサービスを確立
非常に申し訳ありませんが、機密性の高い情報は、あなたが理解することは悪いあまりにも抽象的に感じた場合は、以下を参照してください、そこにマッピングすることはできませんDDD階：ビジネスアナリストや建築家の完璧なペアを
新しいマイクロサービス部門の規格
我々はマイクロサービスの分類のための新しい基準を提案します
標準のマイクロサービス部門のためのコンテキストをゲージにOK
部門は、コンテキストを測定することは困難であるが、それを実行する必要があります。有界コンテキストは薄い空気のうち、しかし関連エンティティ関係から、ビジネスの人々とのコミュニケーションから作られていません。
サービスの進化は単位として進化コンテキストを制限されています
我々は、フィールドインキュベーターとしてマイクロを取る前に、実際には、それが新たな要件に考えて全体的なビジネスの知識、そしてビジネスを与えることです。
当社の新規事業は、すべての車輪の再発明、新製品ではありません。ほとんどの時間、それはビジネスの特定の種類に問題を解決することです。何も取らないための手段としてだけで同じではありません。
だから我々は、既存のコンテキストに入れて、その本質を掘るする必要があります。開発の所有者のためのサービス、1の各マイクロコンテキストは、彼がこの分野では何のために責任があります。
各サービスはハッチ新しい分野を持つように。
例えば
電気の供給業者により、例えば、唯一の新興企業ならば、アリババに同じアーキテクチャ、サービスの何百も関連することはできません。しかし、電子ビジネスの問題の分野のソリューションを抽象化することができます。
有界コンテキスト
複数のコンテキストを取引分かれ人、モノ、ゲーム、。そして、縦型電気プロバイダ会社である、これらの基本的な事は確かにあなたのコアドメインではありませんあなたはなど、あなたのビジネスドメインのコア部分である、孵化し、サービスを分割するために継続していき、唯一のドメインのサポート、または他のあなたのビジネスは確かに開発されていません。
マイクロサービス部門
マイクロ境界サービスコンテキストから引き出さ、サービスは、マイクロフィールドを複数含みます。
加えて、我々は効果的に直接依存サービスを減らすことができ、すべてのミクロな相互作用を、以前のUIサービスを放棄し、フロントデスクサービス。
複数の領域が組み合わされた場合にのみ、我々は内部の[UI]サービスの新しい組み合わせを書きます
また有界コンテキストは、このような製品のマーケティングと、同じレベルではない事業組合とシンプルな商品がコモディティドメイン上で、比較的大きい場合、フィールドです。マーケティングの文脈：あなたは、ユーザーがマーケティングを行うためには、マーケティングのために買い物をする必要がある場合には、明らかに彼は商品のコンテキストであってはならない、それは別の有界コンテキストとして分社することができます。
関連読書
关注【方丈的寺院】，第一时间收到文章的更新，与方丈一起开始技术修行之路