Goでクリーンなアーキテクチャ

私の名前はエドガー（ZergsLaw）、私はb2bとb2cのフィンテック開発会社で働いています。私が最初に会社に就職したとき、私は大規模なfintechプロジェクトのチームに入り、「負荷のかかった」小さなマイクロサービスを受けました。このサービスに別のサポートチームをさらに割り当てるために、リファクタリング計画を検討して準備するように指示されました。







「マイ」サービスは、大規模プロジェクトの特定のモジュール間のプロキシです。一見すると、一晩でそれを研究し、より重要なことに取り掛かることができます。しかし、働き始めて、私は自分が間違っていることに気づきました。このサービスは、MVPをテストするタスクを使用して、6か月前に数週間で作成されました。この間ずっと、彼は仕事を拒否しました。彼はイベントやデータを失ったり、書き直したりしました。プロジェクトはチームからチームへと投げ出されました。なぜなら、その作成者でさえ、誰もそれをやりたがらなかったからです。今、彼らがそれのために別のプログラマーを探していた理由が明らかになりました。



「私の」サービスは、貧弱なアーキテクチャと本質的に正しくない設計の例です。私たちは皆、あなたがこれを行うことができないことを理解しています。しかし、なぜそうではないのか、それがどのような結果につながるのか、そしてどのようにすべてを修正しようとするのか、私はあなたに話します。

悪いアーキテクチャが邪魔になる方法

典型的な話：

• MVPを作成します。
  
  
• その上で仮説をテストします。
  
  
• , MVP;
  
  
• ...;
  
  
• PROFIT.
  
  

しかし、これはできません（私たち全員が理解しています）。



システムが急いで構築されている場合、製品の新しいバージョンをリリースし続ける唯一の方法は、スタッフを「膨らませる」ことです。当初、開発者は100％に近い生産性を示していますが、最初の「生の」製品が機能や依存関係で大きくなりすぎると、それを理解するのにますます時間がかかります。



新しいバージョンごとに、開発者の生産性は低下します。コードのクリーンさ、デザイン、アーキテクチャについては誰も考えていません。その結果、コード行の価格が40倍になる可能性があります。







これらのプロセスは、RobertMartinのグラフではっきりと見ることができます。開発者のスタッフがバージョンごとに増加しているという事実にもかかわらず、製品の成長のダイナミクスは減速しているだけです。コストは増加し、収益は減少しており、それはすでにスタッフの削減につながっています。

クリーンなアーキテクチャの課題

アプリケーションがどのように設計および作成されているかは、ビジネスにとって重要ではありません。製品がユーザーが望むように動作し、収益性が高いことは、ビジネスにとって重要です。しかし、時々（時々ではありませんが、頻繁に）、ビジネスはソリューションと要件を変更します。構造が貧弱なため、新しい要件への適応、製品の変更、および新しい機能の追加は困難です。



適切に設計されたシステムは、目的の動作に簡単に適合できます。繰り返しになりますが、Robert Martinは、動作は二次的なものであり、システムが適切に設計されていればいつでも修正できると考えています。



クリーンなアーキテクチャは、プロジェクト内のレイヤー間の通信を促進します。中心となるのは、適用されたタスクを処理するすべてのエンティティを備えたビジネスロジックです。

• すべての外層は、外界と通信するためのアダプターです。 
  
  
• 外界の要素がプロジェクトの中心部分に浸透してはなりません。
  
  

ビジネスロジックは、デスクトップアプリケーション、Webサーバー、マイクロシステムなど、誰であるかを気にしません。「ラベル」に依存するべきではありません。彼女は特定のタスクを実行する必要があります。データベースやデスクトップなど、その他はすべて詳細です。



クリーンなアーキテクチャにより、独立したシステムが得られます。たとえば、データベースやフレームワークのバージョンに依存しません。ビジネスロジックの内部コンポーネントを変更することなく、サーバーのニーズに合わせてデスクトップアプリケーションを置き換えることができます。これがビジネスロジックの価値です。



クリーンなアーキテクチャは、プロジェクトの認識の複雑さ、サポートコストを削減し、プログラマーの開発とさらなるメンテナンスを簡素化します。 

「悪い」アーキテクチャを特定する方法

プログラミングには「悪い」アーキテクチャの概念はありません。貧弱なアーキテクチャの基準があります：剛性、不動、強靭さ、過度の再現性。たとえば、これらは私のマイクロサービスのアーキテクチャが悪いことを理解するために使用した基準です。



剛性。小さな変更でもシステムが対応できないため、システム全体にダメージを与えずにプロジェクトの一部を変更することが困難になると、システムは堅固になります。たとえば、1つの構造がプロジェクトの複数のレイヤーで一度に使用される場合、その小さな変更によってプロジェクト全体で一度に問題が発生します。



この問題は、各レイヤーで変換することで解決されます。各レイヤーが外部オブジェクトを「変換」することによって取得されたオブジェクトのみを操作する場合、レイヤーは完全に独立した不動性になります



..。システムが再利用可能なモジュールへの分離が不十分（または欠如）で構築されたとき。固定システムはリファクタリングが困難です。 



たとえば、データベースに関する情報がビジネスロジックの領域に入ると、データベースを別のデータベースに置き換えると、すべてのビジネスロジックがリファクタリングされます。



粘度。パッケージ間の責任の分割が不必要な集中化につながる場合。興味深いことに、逆に、粘度が分散化につながると、すべてが小さすぎるパッケージに分割されます。 Goでは、これは循環インポートにつながる可能性があります。たとえば、これはアダプタパケットが追加のロジックの受信を開始したときに発生します。



過度の再現性..。 Goでは、「小さなコピーは小さな依存関係よりも優れている」というフレーズが一般的です。しかし、これは依存関係が少ないという事実にはつながりません-それはただより多くのコピーになります。異なるGoパッケージの他のパッケージからのコードのコピーをよく目にします。



たとえば、Robert Martinは、彼の著書「Clean Architecture」に、過去にGoogleが可能な限り文字列を再利用し、それらを別々のライブラリに割り当てる必要があると書いています。これにより、小さなサービスの2〜3行が変更され、他のすべての関連サービスに影響が出ました。同社はまだこのアプローチの問題を修正しています。



リファクタリングしたい..。これは悪いアーキテクチャのボーナス基準です。しかし、ニュアンスがあります。プロジェクトがどれほどひどく書かれたとしても、あなたが書いたかどうかにかかわらず、最初から書き直してはいけません。これは追加の問題を引き起こすだけです。反復リファクタリングを実行します。

比較的正確に設計する方法

「私の」プロキシサービスは6か月間存続し、この間ずっとそのタスクを実行しませんでした。彼はどうやってそんなに長く生きたのですか？



企業が製品をテストし、それが無効であることが示された場合、その製品は放棄または破棄されます。これは正常です。 MVPがテストされ、それが効率的であることが判明した場合、それは存続します。しかし、通常、MVPは書き直されず、「現状のまま」で動作し、コードと機能が大きくなりすぎます。したがって、MVP用に作成された「ゾンビ製品」は一般的な方法です。プロキシサービスが



どのように機能していないかを知ったとき、チームはそれを書き直すことにしました。このビジネスは私と同僚に割り当てられ、2週間割り当てられました。ビジネスロジックはほとんどなく、サービスは小規模です。これは別の間違いでした。



サービスは完全に書き直され始めました。コードの一部を切り取り、書き直してテスト環境にアップロードすると、プラットフォームの一部がクラッシュしました。このサービスには、誰も知らない文書化されていないビジネスロジックがたくさんあることが判明しました。同僚と私は失敗しましたが、これはサービスロジックのエラーです。



反対側からリファクタリングに取り組むことにしました。

• 前のバージョンにロールバックします。
  
  
• コードは書き直されません。
  
  
• コードをパーツ（パッケージ）に分割します。
  
  
• 各パッケージは個別のインターフェースにラップされています。
  
  

誰も理解していなかったので、サービスが何をしているのか理解できませんでした。したがって、サービスをパーツに「ソーイング」し、各パーツが何を担当しているかを把握することが唯一のオプションです。



その後、各パッケージを個別にリファクタリングすることが可能になりました。サービスの各部分を個別に修正したり、プロジェクトの他の部分に実装したりできます。同時に、サービスの作業は今日まで続いています。 





こんな感じでした。



最初から「うまく」設計した場合、同様のサービスをどのように作成しますか？ユーザーを登録して承認する小さなマイクロサービスの例を紹介します。

入門

システムのコア、外部モジュールを操作することによってビジネスロジックを定義および実行するエンティティが必要です。

type Core struct {
userRepo     UserRepo
sessionRepo  SessionRepo
hashing      Hasher
auth         Auth
}

次に、リポジトリレイヤーを使用できるようにする2つのコントラクトが必要です。最初の契約は私たちにインターフェースを提供します。その助けを借りて、ユーザーに関する情報を格納するデータベース層と通信します。

// UserRepo interface for user data repository.
type UserRepo interface {
    // CreateUser adds to the new user in repository.
    // This method is also required to create a notifying hoard.
    // Errors: ErrEmailExist, ErrUsernameExist, unknown.
    CreateUser(context.Context, User, TaskNotification) (UserID, error)
    // UpdatePassword changes password.
    // Resets all codes to reset the password.
    // Errors: unknown.
    UpdatePassword(context.Context, UserID, []byte) error
    // UserByID returning user info by id.
    // Errors: ErrNotFound, unknown.
    UserByID(context.Context, UserID) (*User, error)
    // UserByEmail returning user info by email.
    // Errors: ErrNotFound, unknown.
    UserByEmail(context.Context, string) (*User, error)
    // UserByUsername returning user info by id.
    // Errors: ErrNotFound, unknown.
    UserByUsername(context.Context, string) (*User, error)
}

2番目の契約は、ユーザーセッションに関する情報を格納するレイヤーと「通信」します。

// SessionRepo interface for session data repository.
type SessionRepo interface {
   // SaveSession saves the new user Session in a database.
   // Errors: unknown.
   SaveSession(context.Context, UserID, TokenID, Origin) error
   // Session returns user Session.
   // Errors: ErrNotFound, unknown.
   SessionByTokenID(context.Context, TokenID) (*Session, error)
   // UserByAuthToken returning user info by authToken.
   // Errors: ErrNotFound, unknown.
   UserByTokenID(context.Context, TokenID) (*User, error)
   // DeleteSession removes user Session.
   // Errors: unknown.
   DeleteSession(context.Context, TokenID) error
}

ここで、パスワードを操作し、ハッシュし、比較するためのインターフェイスが必要です。また、認証トークンを操作するための最新のインターフェイス。これにより、認証トークンを生成して識別できるようになります。

// Hasher module responsible for working with passwords.
type Hasher interface {
   // Password returns the hashed version of the password.
   // Errors: unknown.
   Password(password string) ([]byte, error)
   // Compare compares two passwords for matches.
   Compare(hashedPassword []byte, password []byte) error
}

// Auth module is responsible for working with authorization tokens.
type Auth interface {
// Token generates an authorization auth with a specified lifetime,
// and can also use the UserID if necessary.
// Errors: unknown.
Token(expired time.Duration) (AuthToken, TokenID, error)
// Parse and validates the auth and checks that it's expired.
// Errors: ErrInvalidToken, ErrExpiredToken, unknown.
Parse(token AuthToken) (TokenID, error)
}

ロジック自体を書き始めましょう。主な質問は、アプリケーションのビジネスロジックに何が必要かということです。

• ユーザー登録。
  
  
• メールとニックネームを確認しています。
  
  
• 承認。
  
  

チェック

簡単な方法から始めましょう-メールやニックネームをチェックします。UserRepoには確認する方法がありません。ただし、これらは追加しません。ユーザーにこのデータを要求することで、このデータまたはそのデータがビジーであるかどうかを確認できます。

// VerificationEmail for implemented UserApp.
func (a *Application) VerificationEmail(ctx context.Context, email string) error {
   _, err := a.userRepo.UserByEmail(ctx, email)
   switch {
   case errors.Is(err, ErrNotFound):
      return nil
   case err == nil:
      return ErrEmailExist
   default:
      return err
   }
}

// VerificationUsername for implemented UserApp.
func (a *Application) VerificationUsername(ctx context.Context, username string) error {
   _, err := a.userRepo.UserByUsername(ctx, username)
   switch {
   case errors.Is(err, ErrNotFound):
      return nil
   case err == nil:
      return ErrUsernameExist
   default:
      return err
   }
}

ここには2つのニュアンスがあります。



エラーチェックをErrNotFound行うのはなぜですか？ビジネスロジックの実装は、SQLやその他のデータベースに依存してはならないsql.ErrNoRowsため、ビジネスロジックに便利なエラーに変換する必要があります。



また、APIレイヤーを使用してビジネスロジックレイヤーのエラーを発生させます。エラーコードなどは、APIレベルで解決する必要があります。ビジネスロジックは、クライアントとの通信プロトコルに依存してはならず、これに基づいて決定を下す必要があります。

登録と承認

// CreateUser for implemented UserApp.
func (a *Application) CreateUser(ctx context.Context, email, username, password string, origin Origin) (*User, AuthToken, error) {
   passHash, err := a.password.Password(password)
   if err != nil {
      return nil, "", err
   }
   email = strings.ToLower(email)

   newUser := User{
      Email:    email,
      Name:     username,
      PassHash: passHash,
   }

   _, err = a.userRepo.CreateUser(ctx, newUser)
   if err != nil {
      return nil, "", err
   }

   return a.Login(ctx, email, password, origin)
}

// Login for implemented UserApp.
func (a *Application) Login(ctx context.Context, email, password string, origin Origin) (*User, AuthToken, error) {
	email = strings.ToLower(email)

	user, err := a.userRepo.UserByEmail(ctx, email)
	if err != nil {
		return nil, "", err
	}

	if err := a.password.Compare(user.PassHash, []byte(password)); err != nil {
		return nil, "", err
	}

	token, tokenID, err := a.auth.Token(TokenExpire)
	if err != nil {
		return nil, "", err
	}

	err = a.sessionRepo.SaveSession(ctx, user.ID, tokenID, origin)
	if err != nil {
		return nil, "", err
	}

	return user, token, nil
}

これは、読みやすく、保守しやすいシンプルで必須のコードです。設計時にこのコードをすぐに書き始めることができます。ユーザーを追加するデータベース、クライアントとの通信に選択するプロトコル、またはパスワードのハッシュ方法は関係ありません。ビジネスロジックはこれらすべてのレイヤーに関心があるわけではなく、アプリケーション領域のタスクを実行することだけが重要です。

シンプルなハッシュレイヤー

どういう意味ですか？すべての外部の非レイヤーは、アプリケーション領域に関連するタスクについて決定を下すべきではありません。彼らは私たちのビジネスロジックが必要とする特定の単純なタスクを実行します。たとえば、パスワードをハッシュするためのレイヤーを考えてみましょう。

// Package hasher contains methods for hashing and comparing passwords.
package hasher

import (
   "errors"

   "github.com/zergslaw/boilerplate/internal/app"
   "golang.org/x/crypto/bcrypt"
)

type (
   // Hasher is an implements app.Hasher.
   // Responsible for working passwords, hashing and compare.
   Hasher struct {
      cost int
   }
)

// New creates and returns new app.Hasher.
func New(cost int) app.Hasher {
   return &Hasher{cost: cost}
}

// Hashing need for implements app.Hasher.
func (h *Hasher) Password(password string) ([]byte, error) {
   return bcrypt.GenerateFromPassword([]byte(password), h.cost)
}

// Compare need for implements app.Hasher.
func (h *Hasher) Compare(hashedPassword []byte, password []byte) error {
   err := bcrypt.CompareHashAndPassword(hashedPassword, password)
   switch {
   case errors.Is(err, bcrypt.ErrMismatchedHashAndPassword):
      return app.ErrNotValidPassword
   case err != nil:
      return err
   }

   return nil
}

これは、パスワードのハッシュおよび比較タスクを実行するためのいくつかの単純なレイヤーです。それがすべてです。彼は痩せていてシンプルで、他に何も知りません。そして、そうすべきではありません。

レポ

ストレージインタラクションレイヤーについて考えてみましょう。



実装を宣言し、実装する必要のあるインターフェイスを示しましょう。

var _ app.SessionRepo = &Repo{}
var _ app.UserRepo = &Repo{}

// Repo is an implements app.UserRepo.
// Responsible for working with database.
type Repo struct {
	db *sqlx.DB
}

// New creates and returns new app.UserRepo.
func New(repo *sqlx.DB) *Repo {
	return &Repo{db: repo}
}

コードの読者に、レイヤーによって実装されているコントラクトを理解させ、リポジトリに設定されているタスクを考慮に入れることができます。

実装に取り​​掛かりましょう。記事を引き伸ばさないために、メソッドの一部のみを示します。

// CreateUser need for implements app.UserRepo.
func (repo *Repo) CreateUser(ctx context.Context, newUser app.User, task app.TaskNotification) (userID app.UserID, err error) {
   const query = `INSERT INTO users (username, email, pass_hash) VALUES ($1, $2, $3) RETURNING id`

   hash := pgtype.Bytea{
      Bytes:  newUser.PassHash,
      Status: pgtype.Present,
   }

   err = repo.db.QueryRowxContext(ctx, query, newUser.Name, newUser.Email, hash).Scan(&userID)
   if err != nil {
      return 0, fmt.Errorf("create user: %w", err)
   }

   return userID, nil
}

// UserByUsername need for implements app.UserRepo.
func (repo *Repo) UserByUsername(ctx context.Context, username string) (user *app.User, err error) {
	const query = `SELECT * FROM users WHERE username = $1`

	u := &userDBFormat{}
	err = repo.db.GetContext(ctx, u, query, username)
	if err != nil {
		return nil, err
	}

	return u.toAppFormat(), nil
}

Repoレイヤーには、シンプルで基本的な方法があります。彼らは「保存、送信、更新、削除、検索」以外の方法を知りません。レイヤーのタスクは、プロジェクトが必要とするデータベースへのデータの便利なプロバイダーになることだけです。

API

クライアントと対話するためのAPIレイヤーがまだあります。



クライアントからビジネスロジックにデータを転送し、結果を返し、すべてのHTTPニーズを完全に満たす必要があります-アプリケーションエラーを変換します。

func (api *api) handler(w http.ResponseWriter, r *http.Request) {
	params := &arg{}
	err := json.NewDecoder(r.Body).Decode(params)
	if err != nil {
		http.Error(w, err.Error(), http.StatusBadRequest)
		return
	}

	origin := orifinFromReq(r)

	res, err := api.app.CreateUser(
		r.Context(), 
		params.Email, 
		params.Username,
		params.Password,
		request,
	)
	switch {
	case errors.Is(err, app.ErrNotFound):
		http.Error(w, app.ErrNotFound.Error(), http.StatusNotFound)
	case errors.Is(err, app.ErrChtoto):
		http.Error(w, app.ErrChtoto.Error(), http.StatusTeapot)
	case err == nil:
			json.NewEncoder(w).Encode(res)
	default:
		http.Error(w, http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError)
	}
}

これで、彼のタスクは終了します。彼はデータを持ってきて、結果を取得し、それをHTTPに便利な形式に変換しました。

クリーンなアーキテクチャが本当に必要なのは何ですか？

それは何のためですか？なぜ特定のアーキテクチャソリューションを実装するのですか？コードの「クリーンさ」のためではなく、テスト容易性のためです。独自のコードを便利、簡単、簡単にテストする機能が必要です。



たとえば、このようなコードは悪いです：

func (api *api) handler(w http.ResponseWriter, r *http.Request) {
	params := &arg{}
	err := json.NewDecoder(r.Body).Decode(params)
	if err != nil {
		http.Error(w, err.Error(), http.StatusBadRequest)
		return
	}

	rows, err := api.db.QueryContext(r.Context(), "sql query", params.Param)
	if err != nil {
		http.Error(w, err.Error(), http.StatusInternalServerError)
		return
	}

	var arrayRes []val
	for rows.Next() {
		value := val{}
		err := rows.Scan(&value)
		if err != nil {
			http.Error(w, err.Error(), http.StatusInternalServerError)
			return
		}
		arrayRes = append(arrayRes, value)
	}

	//        

	err = json.NewEncoder(w).Encode(arrayRes)
	w.WriteHeader(http.StatusOK)
}

注：このコードが悪いことを指摘するのを忘れました。更新前に読んだ場合、これは誤解を招く可能性があります。申し訳ありません。

大きな問題なしにコードをテストできることは、クリーンなアーキテクチャの主な利点です。

データベース、サーバー、プロトコルから抽象化することで、すべてのビジネスロジックをテストできます。アプリケーションの適用されたタスクを実行することだけが重要です。これで、特定の単純なルールに従って、コードを簡単に拡張および変更することができます。



どの製品にもビジネスロジックがあります。優れたアーキテクチャは、たとえば、ビジネスロジックを1つのパッケージにパックするのに役立ちます。そのタスクは、外部モジュールを操作してアプリケーションタスクを実行することです。



しかし、クリーンなアーキテクチャが常に良いとは限りません。時にはそれは悪に変わり、不必要な複雑さをもたらす可能性があります。すぐに完璧に書き込もうとすると、貴重な時間を無駄にしてプロジェクトを失望させてしまいます。あなたは完璧に書く必要はありません-あなたのビジネス目標に基づいてうまく書いてください。

, Golang Live 2020 14 17 . — 14 , — , .