アーキテクチャ

花見は、Clean ArchitectureMonolith Firstの 2つの原則に基づいています。

 

クリーンな建築

このアーキテクチャの主な目的は、製品のコア配信メカニズムのに懸念払うことです。最初のものは、私たちの製品が実装する一連のユースケースで表され、後者は、これらの機能を外部の人々が利用できるようにするインタフェースです。

我々は新しいプロジェクトを生成するとき、私たちは、2つの重要なディレクトリを見つけることができますlib/apps/。彼らは上記の主要な部品の本拠地です。

 

アプリケーションコア

私たちは、外界にどのようにさらされるのか心配することなく、一連の機能を実装します。これは私たちの製品の基盤であり、私たちはそれの依存関係をどのように管理するかを慎重に考えていきたいと考えています。

Hanami::ModelRubyオブジェクトを永続化するためのデフォルトの選択です。これはソフト依存であり、私たちから削除してGemfile他のものに置き換えることができます。

さんはどのように見てみましょうlib/ディレクトリと呼ばれる新しい生成されたプロジェクトのために表示されますbookshelf使用していますHanami::Model

% tree lib
lib
├── bookshelf
│   ├── entities
│   ├── mailers
│   │   └── templates
│   └── repositories
└── bookshelf.rb

5 directories, 1 file

Rubyの宝石のようなアプリケーションを開発することです。

このlib/bookshelf.rbファイルは、アプリケーションのエントリポイントです。このファイルが必要な場合は、すべてのコードを必要とし、初期化しlib/ます。

重要なディレクトリは2つあります。

  • lib/bookshelf/entities
  • lib/bookshelf/repositories

これらのオブジェクトには、モデルドメインのコアであるRubyオブジェクトであるエンティティが含まれており、永続性メカニズムを認識していません。この目的のために、私たちはエンティティと基になるデータベースとの間のメディエータである分離された概念リポジトリを持っています。

名前を付けられた各エンティティに対して、Book私たちはaを持つことができBookRepositoryます。

lib/bookshelf/interactorsユースケースを実装するなど、必要な数だけディレクトリを追加できます。

 

配信メカニズム

Hanamiはデフォルトの名前付きアプリケーションWebを生成しapps/webます。このアプリケーションは、エンティティ、リポジトリ、およびそこに定義されているその他すべてのオブジェクトを使用するため、製品のコアに依存します。

私たちの機能のために、Web配信メカニズムとして使用されています。

% tree apps/web
apps/web
├── application.rb
├── assets
│   ├── favicon.ico
│   ├── images
│   ├── javascripts
│   └── stylesheets
├── config
│   └── routes.rb
├── controllers
├── templates
│   └── application.html.erb
└── views
    └── application_layout.rb

8 directories, 5 files

このコードを簡単に見てみましょう。

このファイルにapps/web/application.rbは、名前を付けられた花見アプリケーションが含まれていWeb::Applicationます。ここでは、プロジェクトのこのコンポーネントのすべての設定を構成できます。ディレクトリのようなapps/web/controllersviewsそしてtemplates私たちの含まれていますアクションビューテンプレートを

javascriptやスタイルシートなどのWebアセットは、アプリケーションによって自動的に提供されます。

 

モノリス・ファースト

私たちのデフォルトアプリケーションWebは、顧客のためのUIインターフェースとして使用できます。私たちの話のある時点では、管理パネルでユーザーを管理したいと考えています。

私たちが紹介しようとしている一連の機能はメインのUI(Web)に属していないことがわかっています。一方、それはだ早すぎる私たちは私たちの唯一のユーザーが自分のパスワードをリセットする手助けのために、microservicesアーキテクチャを実装するため。

Hanamiは私たちの問題を解決するソリューションを持っています:同じRubyプロセスに存在する新しいアプリケーションを生成することはできますが、それは分離されたコンポーネントです。

% bundle exec hanami generate app admin

このコマンドは、プロジェクトのルートから実行する必要があります。Admin::Application下に新しいアプリケーション()が生成されapps/adminます。

製品ライフサイクルの後半に、最終的にこれをスタンドアロンコンポーネントに抽出することができます。すべてのものapps/adminを別のリポジトリに移動し、別々のリポジトリに展開するだけです。

 

プロジェクトの解剖

我々は今まで検討してきましたがlib/、説明apps/されるべき新しいプロジェクトの他の部分があります。

% tree -L 1
.
├── Gemfile
├── Gemfile.lock
├── Rakefile
├── apps
├── config
├── config.ru
├── db
├── lib
└── spec

すぐにそれらを紹介しましょう:

  • Gemfileそして、Gemfile.lockあるバンドラーのアーティファクト
  • Rakefile 私たちのプロジェクトのRakeタスクについて説明します。
  • config/重要なファイルが含まれていますconfig/environment.rb。これは、プロジェクトのエントリーポイントです。それを必要とすることで、依存関係(Ruby gems)、Hanamiフレームワーク、およびコードを事前にロードします。
  • config.ru Rackサーバーがアプリケーションを実行する方法を記述したファイルです。
  • db/データベースファイル(ファイルシステムアダプタまたはSQLite用)が含まれています。私たちのプロジェクトがSQLデータベースを使用するときにはdb/migrations、とも含まれdb/schema.sqlます。
  • spec/ ユニットテストと受け入れテストが含まれています。