Designing Software for a Scalable Enterprise †
序文 †
- 前章で最新のソフトウェアの開発について述べた。
- ここから次のような疑問は湧いてくるだろう。
- 開発者やアーキテクトはさらに俊敏さが求められるエンタープライズソフトウェアをどうデザインしたらいいだろう？
- クラウドとコンテナ技術は新たなサービス基盤となっていて、さらに多くのアプリケーションがマイクロサービスアーキテクチャへの適合しているし、我々がソフトウェアデザインについて知っていることすべてがそれによって変化させられる。
- 言っておくと、ソフトウェアアーキテクチャとデザインの基本コンセプトはステークホルダーの多くの要望を満たし、関心事の課題から分離させ、品質を生み出し、最初のプロトタイプが素晴らしいままで概念上の統一性が保証されていることだ。
- そして、開発者はすでに知られ選ばれている正しいアプローチ課題に対して密接な注意をはらう必要がある。
- マイクロサービスは現在でもバズワードのままだが、生きたデザインパターンでもある。
- また＜密接な検査された>名前はすでに存在したモジュールデザインアーキテクチャのスタイルの新しいの代名詞でもある。
- マイクロサービスは開発者が一枚岩では複雑すぎるシステムを持っている場合には正しい選択肢となる。
- そしてこれはエンタープライズアプリケーションのための妥当な選択をするアーキテクチャスタイルなのだ。
- マーティンハウラーが彼の著書「MicroservicePreminum?」で述べていることから、
- 図3-1を見て欲しい。
- メインのポイントとしては巨大で複雑なシステムを一枚岩で組まれた状態でもっていない限り、マイクロサービスアーキテクチャを使うことは考えなくていいということだ。
- 結果として多くのモダンなソフトウェアシステムはシングルなアプリケーションとして開発されているだろうから、それはモジュラーかつ最先端のソフトウェアアーキテクチャの恩恵を受けることができるだろう。
- Java EEで複雑なシステムを開発していると、システムによってはマイクロサービスアーキテクチャが適すものが見つからない時がある。
- しかしこれは完全な真実ではない。
- 技術的・ビジネス的な複雑さは合うアーキテクチャを選択する唯一理由とはならないからだ。
- 多くの場合の一番の関心事は現在の開発チームのチームのサイズだったりする。
- 開発チームが成長するにつれて、サービスを完全に切り離すのが効率的かつ合理的になってくる。
- しかし、ハードなメトリックスや複雑さが見積もられていない場合は、決断するのは簡単だ。
- ベストな方法はすべての設定の財布のルートを決めておくことだ。
- このスタートはソフトウェアシステムが動作する必要があるという意志とともにある。
Greenfeld Versus Brownfield †
- 何年か前に構築されている多くの現代のエンタープライズソフトウェアはまだ最新のレギュレーションや新しいビジネスの要求に適合させるため-に定期メンテナンスが行われている。
- 完全に新しいビジネスケースか内部的な重大な再構築な場合以外は、一部分を構築するためにソフトウェアをスクラッチから構築することを考えることはまれだろう。
- しかしそれの必要性を評価するか、新しいマイクロサービスアーキテクチャで開発する恩恵がある場合を考えてみよう。
その場合に成功する方法とはなんだろう。
- スクラッチから始める方法か、それとも既存のアプリケーションをサービスとして分裂させる方法か、
- 両方のアプローチはいくつかのリスクとチャレンジがある。
- 通常、両方の方法は小さくしかし、クリティカルである。
- 開発者はビジネスドメインを知る必要がある。
- また下記の詳細を知る必要がある。特にエンタープライズプロジェクトでは長期期間について考えないといけなくて、ドキュメントも散り散りになりやすく、開発者がアクセスできることが重要だ。
- 加えて、筆者は複雑さの影についての判断を知っている。
- 例えばマイグレーションなど。
Domain-Driven Design †
- ドメイン駆動開発の中心はコアとなるビジネスドメインの複雑さに焦点を置いたものだ。
- ドメイン駆動開発は問題領域のモデルを作成することを狙いとしている。
- もっともクリティカルなことはドメインへの理解で、それはソフトウェアデザインのベースとなるものだ。
- ドメイン駆動開発はソフトウェアを開発することのコンセプトを定義し、ソフトウェアの構成をコードで表現することになっている。
- モデルを定義するためにドメイン駆動開発ではBounded Contextというものを利用する。
- 全てのドメインモデルは厳密な一つのBCに生きている。そしてBCはドメインモデルの一つを含む。
- ドメイン駆動開発はドメインレイヤーで機能する。
- ドメインレイヤーはビジネスオブジェクトをのみを含む。
Service Characteristics †
- マイクロサービスについてのサブセクションについて見てみよう。
Core Service †
- コアサービスは特定のドメインの実体を写し、ドメインサービスの定義をフォローするものだ。これにはベースとなる操作や、コンシューマーを- - 含んでいる。
例として、
- Order
- Shipping
- Catalog
- User
- Customer
- プロセスサービスは一つまたは複数のタスクを振る舞う責務であり、ビジネスサービスの定義をフォローするものだ。
- これらは通常コアサービスの一つまたは複数に依存し関連したビジネスプロセスとアクションを代名したものとなる。
- ドメインモデルなしで正しいパーティションを見つけるには、時間がかかり、実装前に考慮する必要がある。
- 異なるビジネスケーパビリティにもフォーカスし続ける必要がある。
- すでに知られている伝統的なアーキテクチャに敬意を払い、ネットワークのレイテンシーとホップに注意することが求めれらる。
- 下記の例のようなものがある。
- このサービスリストはコースを与えるコースリストと同様である。
- このサービスプレイスはカスタマーからのオーダーだ
- このサービス再販ルート
- このサービスログはカスタマーのオーダーステップだ
- もし最初の調査が完了しているのなら、マイクロサービスを構成する基本となる要件について知りたくなるだろう。
担当者のつぶやき †
みんなの突っ込み †
