Goアプリケーションのクリーンアーキテクチャ。 パート1

翻訳者から：この記事は2012年9月にManuel Kiesslingによって 、Go仕様を考慮したクリーンアーキテクチャに関するUncle Bobの記事の実装として書かれました 。







この記事の前に、プロトタイプを翻訳しました- こちらをご覧ください 。 この記事で説明したボブおじさんは、この記事の枠組みの中で積極的に使用されるので、それから始めた方が良いでしょう...もちろん、まだ読んでいないなら。



最初の記事とは異なり、エンティティの代わりにドメインが内部層の名前に表示されます。翻訳では、混乱を避けるためにこの用語を残しました。 私の意見では、この用語はより広い意味を持っているので、私はDomainを Domainとして翻訳しました。



このパートでは、一般的な概念を説明し、内側のレイヤーを使用します。



私の意見では、依存性ルールは、ソフトウェアの開発時に適用すべき最も重要なルールの1つです。テストしやすいシステムを取得したい場合、フレームワーク、UI、またはデータベースに依存しません。 この規則に従うと、最終的にはシステムコンポーネントの接続性が低下し、責任が明確に分離されます。

疎結合システム

テスト可能な部品と弱く相互接続されたコンポーネントで構成されるシステムは、問題なく拡張でき、理解、変更、拡張、スケーリングを透過的に行えます。 依存関係ルールを適用する際に、これらの品質の発現を実証しようとします。



これを行うために、「クリーンアーキテクチャ」の概念をいつ、どのように適用すべきかを同時に議論する、シンプルでありながら本格的なGoアプリケーションを実装します。



このアプリケーションはストアの最小バージョンであり、注文に関連する製品のリストをHTTPリクエストで受け取ることができます。



いくつかのテストカバレッジを含むソースコードはgithubにあります。



ソースコードを理解しやすくするために、製品の表示、注文、支払いなどの他のシナリオは実装しません。 さらに、アーキテクチャの本質を説明するのに役立つコード部分の実装に焦点を当てました。したがって、完全なエラー処理など、コードには他の多くの要素が欠けています。 また、多くの冗長性が含まれていますが、前後にジャンプすることなく、コードを上から下に読むことができます。

アプリケーションアーキテクチャ

まず、アプリケーションのさまざまな領域と、アーキテクチャ内でのそれらの場所を分析します。 アプリケーションのアーキテクチャは、 Domain 、 Scripts 、 InterfacesおよびInfrastructureの 4つのレイヤーに分割されます。 最も内側の層から始めて、各層を高レベルの位置から説明します。 次に、各レイヤーの低レベルの実装を見て、内側のレイヤーから外側のレイヤーに移動します。



私たちのアプリケーションのドメイン 、またはビジネス-人々は購入のために、またはより正式な方法で店に来ます。顧客は注文に商品を追加します。 これらのビジネスオブジェクトとそのルールを、内部層、ドメイン層のコードとして提示する必要があります。

何を入れて、なぜ

ユーザーについてではなく、顧客について話すことにしました。 私たちのアプリケーションには確かにユーザーがいますが、アプリケーションドメインについて話すとき、ユーザーは関心を持ちません。 責任分担を真剣に受け止めたいのであれば、「ユーザー」はシナリオを扱うがビジネスそのものを扱うのではないので、「ユーザー」をどのレイヤーに入れるかを非常に正確に考える必要があると思います。



当然のことながら、ソフトウェア開発者として、ソフトウェア形式の観点から物事を見ることに慣れています。 したがって、アーキテクチャを議論する間、いくつかの不快な微妙さによるミスを避けるために、私はコンピュータに関する比phorを避けようとします。 ビジネスドメインがプログラムの一部ではなく、たとえばボードゲームの一部であると想像したらどうでしょうか。



ボードゲームとしてeBayまたはAmazonを実装する必要があると想像してください。 eBayサイトとeBayボードゲームには、買い手、売り手、製品、入札が必要ですが、ユーザー、セッション、Cookie、認証などが必要なのはeBayサイトだけです。



プログラムが小さい場合、ユーザーと顧客が同一であるという決定は大したことではないように見えるため、これはかなり微妙な違いです。 しかし、これは後で修正するのが難しいものの1つです。 その理由は、99％の状況で、ユーザーと顧客が同じであるという仮定は、残りの1％が作用するまでまったく意味がないということです。 この状況をアプリケーションで説明します。



したがって、注文と商品はドメイン層に属しますが、ユーザーは次の層-スクリプトに属します。



スクリプトレイヤーに属する他のものは何ですか？ シナリオは、アプリケーションユーザーがベースドメインのサブジェクトで「何かをする」必要があるために発生するユースケースが実現される層です。 ユースケースの例は「顧客が注文に商品を追加する」でしょう。 このユースケースおよびその他のユースケースを実装するには、ビジネスエンティティを「起動」するメソッドを実装する必要があります。



これはドメイン層で実装できますが、スクリプトでこれを行うことをお勧めします。 この主な理由は、スクリプトはアプリケーション固有であり、ドメインエンティティはそうではないためです。 2つのアプリケーションを想像してください。1つは顧客が物を表示して購入できるもの、もう1つは管理者が注文の管理と実行に使用するものです。 ドメインのエンティティは両方のアプリケーションで同じままですが、使用シナリオは非常に異なります：「注文に製品を追加する」と「注文を配信済みとしてマークする」。 ドメイン層とスクリプト層は一緒になってアプリケーションのコアを形成し、連携するビジネスの現実を表します。 それ以外はすべて、実装の詳細であり、ビジネスの機能とは関係ありません。 ストアは、Webサイトまたはデスクトップアプリケーションとして実装できます-ドメインエンティティとその使用シナリオに触れない限り、これは同じビジネス指向のアプリケーションです。



WebサービスをHTTPからSPDYに、またはデータベースをMySQLからOracleに切り替えることができます-これにより、商品（ドメイン）で構成される顧客と、注文を作成し、数量を変更できる顧客がいるという事実は変わりません商品と支払いオプション（シナリオ）



同時に、これは内部レイヤーのリトマステストです。MySQLからOracleに切り替えるときに少なくとも1行のコードを変更する必要がありますか？



答えが「はい」の場合、内側の層の一部が外側の層の詳細に依存するように、依存関係の規則に違反しました。



また、データベースと連携したり、HTTPリクエストや外部サービスを処理したりするコード用の場所もあります。 この場所はインターフェースのレイヤーです。



たとえば、アプリケーションがWebサイトとして使用可能になった場合、HTTPサーバーとアプリケーションレイヤー間のインターフェイスを形成するため、着信HTTP要求を処理するコントローラーはインターフェイスレイヤーに配置されます。 外部からのこれらのイベント-トリガーされたHTTPリクエスト、UIでのマウスクリック、またはリモートプロシージャコール-は、アプリケーションでアクティビティを作成します。 それらがなければ、スクリプトメソッドとドメインエンティティは無駄になります。 しかし、内側の層の要素は外側の世界と相互作用（および一般的には認識）できないため、外側の世界からのイベントを内側の層のアクションに変換するにはインターフェースが必要です。



ストアデータ（データベース内の商品、注文、ユーザー）を保存する場合は、データベースへのインターフェイスも必要です。 依存性ルールの適用が特に興味深いのはここです。SQLコードがInterfacesレイヤーに存在し、同時に内側のレイヤーから外側のレイヤーを呼び出すことができない場合、保存はスクリプトレベルで初期化されます。依存ルール？ コードの実装により近いところで、これを詳細に分析します。



最後の層はインフラストラクチャと呼ばれます。 インフラストラクチャに属するものとインターフェイスに属するものの分離は必ずしも容易ではありません。 たとえば、両方のレイヤーには、データベースと通信するコードなど、外の世界と相互作用するコードが含まれています。 ここでの決定要因は、インターフェイスコードがプログラムに固有であり、インフラストラクチャコードがまったく異なるため、まったく異なるアプリケーションで使用できることです。 たとえば、アプリケーションでHTTPリクエストを処理する関数は、このアプリケーションのフレームワーク内でのみ意味があり、HTTPを操作するための標準のGoライブラリは汎用コードであり、他のアプリケーションで使用できます。 この意味で、標準のGoライブラリのほとんどは、概念的にはインフラストラクチャレイヤーにあります。



アプリケーションのすべてのレイヤーとパーツのリストを作成するために線を引きましょう：



ドメイン：

• 顧客の本質
• 製品の本質
• エンティティの順序

シナリオ：

• ユーザーエンティティ
• シナリオ：注文に製品を追加する
• シナリオ：注文アイテムのリストを取得する
• シナリオ：管理者が製品を注文に追加します

インターフェース：

• 製品/注文処理用のWebサービス
• スクリプトおよびドメインエンティティのリポジトリ

インフラ

• データベース
• データベース接続を処理するコード
• HTTPサーバー
• Go標準ライブラリ

ご覧のように、このリストにはまだ説明していない要素が含まれています-実装について説明するときに、管理スクリプトとリポジトリを詳細に調べます。



そして、コードを掘り下げる前の最後の考え。 アプリケーションの分割方法を見ると、特定のテンプレートが強調表示されます。 レイヤーを見て、ビジネス依存コードとアプリケーション固有コードの2つの方法でレイヤーを分解しようとすると、次の図が表示されます。

インフラ	インターフェース	シナリオ	ドメイン
アプリケーションに依存しない	アプリケーション固有	アプリケーション固有	アプリケーションに依存しない
独立した企業	独立した企業	ビジネス固有	ビジネス固有

たとえば、ここからコードはアプリケーションに依存しないコードであり、ビジネスはインフラストラクチャ層に実装する必要があることがわかります。



左に移動するほどコードが低くなり（「80番目のポートにバイトストリームを転送する」）、右に移動するほどコードが高くなります（「注文に商品を追加する」）。

実装

ドメイン

まず、ドメインレイヤーを実装します。 前述のように、アプリケーションは完全に機能しますが、同時に完全なストアになることはありません。 したがって、ドメインを実装するコードは十分に短くなり、単一のファイルに実装します。

// $GOPATH/src/domain/domain.go package domain import ( "errors" ) type CustomerRepository interface { Store(customer Customer) FindById(id int) Customer } type ItemRepository interface { Store(item Item) FindById(id int) Item } type OrderRepository interface { Store(order Order) FindById(id int) Order } type Customer struct { Id int Name string } type Item struct { Id int Name string Value float64 Available bool } type Order struct { Id int Customer Customer Items []Item } func (order *Order) Add(item Item) error { if !item.Available { return errors.New("Cannot add unavailable items to order") } if order.value()+item.Value > 250.00 { return errors.New(`An order may not exceed a total value of $250.00`) } order.Items = append(order.Items, item) return nil } func (order *Order) value() float64 { sum := 0.0 for i := range order.Items { sum = sum + order.Items[i].Value } return sum }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードが依存関係に重要なものを持たないことはすぐに明らかです。一部のメソッドがエラーを返すため、「エラー」パッケージのみをインポートしました。 ここで説明するドメインエンティティは最終的にデータベース内の文字列になりますが、このレイヤーにはデータベースに関連付けられたコードはありません。



代わりに、3つのいわゆるリポジトリーのGoインターフェースを定義します。 リポジトリはDDD（Domain Driven Design）の概念です。永続ストレージを操作する何らかのメカニズムでエンティティを保存または取得する必要があるという事実からの抽象化の方法です。 ドメインの観点から見ると、リポジトリは単にドメインエンティティが取得（FindById）または格納（ストア）されるコンテナです。



CustomerRepository、ItemRepository、OrderRepositoryは単なるインターフェイスです。 データベースとアプリケーション間のインターフェイスを実装するため、これらはInterfacesレイヤーの一部として実装されます。 これが、依存関係ルールをGoアプリケーションに実装する方法です。これは、外側のレイヤーには何も適用せず、内側のレイヤーには定義しない抽象的なインターフェイスです。 その実装は外側の層で決定されます。 インターフェイスの実装はその層で行われ、後で使用する必要があります。 これは、後でScriptsレイヤーに到達したときに表示されます。



したがって、スクリプトレイヤーは、ドメインレイヤーの概念をリポジトリを通じて参照できますが、ドメインレイヤーでは純粋なGoのみを使用します。 ただし、実際には、コードはInterfacesレイヤーで実行されます。



各層の各部分には、3つの質問があります。それはどこで使用され、そのインターフェースはどこに、実装はどこにありますか？



OrderRepositoryを見ると、答えは次のようになります。スクリプトレイヤーで使用され、そのインターフェイスはドメインレイヤーに属し、その実装はインターフェイスレイヤーに属します。



一方、OrderエンティティのAddメソッドはScriptsレイヤーでも使用され、実際にはDomainレイヤーへのインターフェイスです。 ただし、このメソッドはそれ以外の要素を実際に必要としないため、その実装はドメイン層で実行されます。



また、次の3つの構造を定義します：顧客（顧客）、注文（注文）、アイテム（製品）。 これは、3つのドメインエンティティを表しています。 Orderエンティティも2つのAddメソッドとvalueメソッドによって実装され、valueは内部使用専用の補助関数です。 Addメソッドは、スクリプト層での使用に必要なビジネス固有の機能を実装します。



また、このコードには、アーキテクチャ全体に関して重要な追加の詳細があります。 ご覧のとおり、アプリケーションにはさまざまな場所にいくつかのルールがあり、どのルールがどのルールに属するのかを議論する必要があります。



最初のルールは、利用できない商品の順序に加えて定義します-これは明らかにビジネスルールです。 顧客がアクセスできない商品を注文に追加しないようにすることは、オンラインストアで注文する場合、たとえば電話でオペレーターを通して注文する場合に適用されるルールです。 このルールはアプリケーション固有ではなく、ビジネス要件です。



注文が250ドルの合計費用を超えることはできないというルールについても同じことが言えます。ストアがウェブサイトであるかボードゲームであるかは関係ありません。これは常に適用されるビジネスルールです。



他のルールは他の場所で定義されています。 たとえば、商品のコストをデータベースに保存し、フィールドタイプを浮動にする必要がありますが、これはビジネスルールではなく技術的なルールであり、ドメインレイヤーに属していません。



一方、注文を保存するときのデータベースへのインターフェイスのコードは、250米ドルを超える注文を完全に保存できます。これは、ビジネスルールに起因する制限であり、データベースへのインターフェイスはそのようなことを心配する必要がないためです。 この例は、ボブおじさんの原則が大好きな理由の素晴らしい例です。250ドルの注文制限がデータベースのストアドプロシージャに実装されていることを想像してください。 時間が経つにつれて、これらのルールはさまざまな場所に広がり、アプリケーションが大きくなるほど、維持が難しくなります。 常にすべてのビジネスルールを1か所にまとめることを好みます。



次の部分に続きます。