Another works Developers Blog

<p>こんにちは、ノブです。</p>
<p>データドリブンな意思決定をよりスピーディに行うために分析工程をより速く・正確に行う方法がないかを日々試行錯誤しています。</p>
<p>その中の試みの一つについて記載します。</p>
<p>運用から３ヶ月程度経過し、効果を実感しているため、同じような悩みをお持ちの方の何かヒントになればとても嬉しく思います。</p>
<h3>分析工程のボトルネック</h3>
<p>分析の速度・正確性を考えた時に分析業務を以下の３つに大別しました。</p>
<ul>
<li>
<p>分析を計画する<br>
　- 明確にしたいものを定義する<br>
　- 分析にあたっての取得するデータを定義する<br>
　- どのような分析、可視化を行うかを考える</p>
</li>
<li>
<p>データを取得する<br>
　- DBの中身を把握する<br>
　- クエリを考える<br>
　- 可視化を行う</p>
</li>
<li>
<p>分析をする<br>
　- 可視化したものや情報を元に実際に分析を行う<br>
　- 議論できるように結果をレポーティングする</p>
</li>
</ul>
<p>この中で特に時間がかかっていて改善の余地が見込まれたのが「データを取得する時間」でした。</p>
<h3>複業クラウドにおける BigQuery</h3>
<p>複業クラウドでは、ログデータや同期したマスタテーブルを分析用に整形せずに生に近い状態で BigQuery に蓄積しており、データレイクとして活用していました。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/1857e4dc-e5c4-49af-aa1f-e1d4f3f81dee%2Ftech_blog.001.jpeg" alt="tech_blog.001.jpeg"></p>
<p>上図のように分析者や BIツールはこの BigQuery を参照してデータ取得を行っていましたが、生データに近いが故に以下の課題を持っていました。</p>
<ul>
<li>分析に不要な情報が多く存在する</li>
<li>値や構造が実装者寄りで分析者寄りではない</li>
</ul>
<p>一つ目の「分析に不要な情報が多く存在する」についてです。<br>
同期したマスタテーブルでは、どの分析でも落としている情報がありました。<br>
例えば、求人データの公開日は重要ですが同じテーブルに存在するシステムで出し分けのために使っている値は分析では必ず落としていました。</p>
<p>二つ目の「値や構造が実装者寄りで分析者寄りではない」についてです。<br>
システムとしての良いテーブル構造が必ずしも分析にとって都合の良い構造ではないということは良くあることだと思います。<br>
具体的には、分析を目的とした SQL では結合や条件句が非常に多くなってしまい可読性やメンテナンス性に乏しいクエリとなっていました。</p>
<h3>解決策</h3>
<p>解決策として DWH（データウェアハウス）を作成することとしました。<br>
DWH は目的を分析に絞り、不要な情報は先に落とし、構造も分析寄りにしました。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/c9251136-61eb-49f6-b5fd-08f57517207e%2Ftech_blog.002.jpeg" alt="tech_blog.002.jpeg"></p>
<p>DWH を設けることは BigQuery のビューを使うことで容易にできたので利用サービスが増えることもありませんでした。</p>
<p>ビューの使用方法は<a href="https://cloud.google.com/bigquery/docs/views?hl=ja#console">公式のドキュメント</a>に記載されているため割愛しますが、得られた効果を考えるとビューを用いた DWH の作成コストは非常に小さいと改めて感じています。</p>
<h3>効果</h3>
<p>DWHの運用は、効果を十分に感じています。</p>
<p>得られた効果は大きく二つあります。</p>
<ul>
<li>クエリが簡潔になった</li>
<li>分析用の単語の定義にブレがなくなった</li>
</ul>
<p>どちらの効果も分析のスピードをあげるだけでなく人的ミスを減らすことにも貢献してくれています。<br>
また、今後分析を担当するメンバーが増えた際にも全てのテーブルの関係性を説明するのではなく、目的にそった DWHを説明すれば良くなりました。</p>
<h3>まとめ</h3>
<p>今回は BigQuery のビューを用いて DWH を設けた話をさせていただきました。<br>
DWH を作成すると、今後はデータマートを作成することも容易となり、またこの話もできればと思っています。</p>
<p>サービスの進化に合わせて保持するデータは常に変わっていくもので、それを途切れることなく貯めていく分析基盤は非常に難しく魅力的なものですが、分析のための正しいデータ運用をこれからも模索できればと思っています。</p>


BigQueryのビューでDWHを作る

<p>こんにちはAnother works CTOの塩原です。</p>
<p>複業クラウドのバックエンドではDDDとクリーンアーキテクチャを導入しています。</p>
<p>社内では、<a href="https://twitter.com/little_hand_s">松岡さん</a>の書籍やTwitterなどを参考にしながらDDDの開発に取り組んでいます。</p>
<p>DDDの記事は参考になるものが松岡さんの記事やその他の人が書いた記事など豊富にあるため、設計方法についてはそこまで困ることはありません。</p>
<p>DDDの記事を見ているとJavaやKotlin、Scalaだったり、一部フレームワーク独自構文を使ってDDDを実装しているものも多いため、今回はTypescriptで実装するための方法を記事にすることで、Node.jsを使っている方や、Typescriptを使っている方に参考になればと思い、書かせていただきました。</p>
<h1>この記事で書くこと・書かないこと</h1>
<h2>書くこと</h2>
<ul>
<li>ドメインイベントをTypescriptで実装する方法</li>
</ul>
<h2>書かないこと</h2>
<ul>
<li>ドメインイベントを始め、DDDに関する説明</li>
</ul>
<h1>シナリオ</h1>
<p>求人作成した際に、求人のデータなどを把握することができる求人レポートを生成することができる</p>
<h3>簡易ドメイン図</h3>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/d788e481-82e5-4a50-90d5-36177a978ec8%2F%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882022-12-1914.46.59.png" alt="スクリーンショット2022-12-1914.46.59.png"></p>
<h3>イベント周りの処理フロー図</h3>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/9f479852-ad4c-40cd-90b6-b57992fc4188%2F%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882022-12-1914.53.43.png" alt="スクリーンショット2022-12-1914.53.43.png"></p>
<h1>ドメインイベント</h1>
<p>まずはドメインイベントクラスを実装します</p>
<p>EventListenerでイベントごとに実行する処理を変える必要があるので、nameで判断できるようにします</p>
<pre><code class="language-tsx">export type DomainEventName = 'projectCreateEvent'

export interface DomainEvent {
    name: DomainEventName
}

type ProjectInfo = {
  title: string
}

/**
 * 求人作成イベント
 */
export class ProjectCreateEvent implements DomainEvent {
    name: 'projectCreate' = 'projectCreate'
    projectInfo: ProjectInfo

    constructor(params: { projectInfo: ProjectInfo }) {
        this.projectInfo = params.projectInfo
    }
}
</code></pre>
<h1>ドメインイベントの生成</h1>
<p><code>DomainEventStorable</code> という抽象クラスで、エンティティーがイベントを保持するための機能を抽象化しています。</p>
<p><code>ProjectDomainModel</code>で継承し、create関数の中で <code>ProjectCreateEvent</code> を発火するようにしています。</p>
<pre><code class="language-tsx">export abstract class DomainEventStorable {
    private domainEvents: DomainEvent[] = []

    protected addDomainEvent(domainEvent: DomainEvent) {
        this.domainEvents.push(domainEvent)
    }

    getDomainEvents(): DomainEvent[] {
        return this.domainEvents
    }

    clearDomainEvents() {
        this.domainEvents = []
    }
}

export default class ProjectDomainModel extends DomainEventStorable {
  constructor() {
    super()
    //...
  }

  static create(title: string) {
    //...
    // 
    model.addDomainEvent(
        new ProjectCreateEvent({
            projectInfo: {
                title
            },
        })
    )
  }
}
</code></pre>
<h1>イベント発行処理</h1>
<p>Node.jsにはEventEmitterという標準クラスがあり、イベント処理など行えるので <code>DomainEventListener</code> というクラスを使ってイベント処理をラップしています。</p>
<p><code>DomainEventPublisherImpl</code> はイベントを発行する処理で <code>ProjectRepositoryImpl</code> の関数の引数に渡して、repository内でpublish処理を行うようにする</p>
<p>publishする処理はドメインイベント全体で共通となっているので、ドメインイベントごとに作成する必要はありません。</p>
<pre><code class="language-tsx">import EventEmitter from 'events'

const emitter = new EventEmitter()
emitter.setMaxListeners(0)
export class DomainEventListener {
    static on&lt;T extends DomainEvent&gt;(
        eventName: T['name'],
        callback: (event: T) =&gt; void
    ) {
        emitter.on(eventName as string, callback)
    }

    static emit(eventName: DomainEvent['name'], event: DomainEvent) {
        emitter.emit(eventName as string, event)
    }
}

export interface DomainEventPublisher {
    publish(event: DomainEvent): Promise&lt;void&gt;
}

export class DomainEventPublisherImpl implements DomainEventPublisher {
    async publish(event: DomainEvent): Promise&lt;void&gt; {
        try {
            DomainEventListener.emit(event.name, event)
            new DomainEventEntity(DotEnvConsts.getFcLoggerEnv())
                .setData({
                    eventInfo: JSON.stringify(event),
                    eventName: event.name,
                    time: new DateLib().formatDate(
                        new Date(),
                        'YYYY-MM-DD HH:mm:ss'
                    ),
                })
                .save()
        } catch (e) {
            SentryLib.captureException(e)
            LoggerLib.error(`${event.name}: ${e};event: ${event}`)
        }
    }
}

export class ProjectRepositoryImpl implements ProjectRepository {
  async save(
        model: ProjectDomainModel,
        publisher: DomainEventPublisher
    ): Promise&lt;void&gt; {
    // 保存処理
    model.getDomainEvents().forEach((event) =&gt; publisher.publish(event))
  }
}
</code></pre>
<h1>イベントリスナー</h1>
<p>イベントリスナークラスはドメインごとに複数作成します。</p>
<p>今回イベントを受け取って振る舞いを定義するのはProjectReportになるので、 <code>ProjectReportListener</code>として作成して受け取ったイベントの振る舞いを定義しています。</p>
<pre><code class="language-tsx">export class ProjectReportEventListener {
  
  constructor(private repository: ProjectReportRepository) {
        DomainEventListener.on&lt;ProjectCreateDomainEvent&gt;(
            'projectCreate',
            (event: ProjectCreateDomainEvent) =&gt;
                this.callback(event)
        )
  }
  
  private callback(event: ProjectCreateDomainEvent) {
    // repositoryを使って、ProjectReportのsave処理を行う
  }
}

// index.ts
createConnection().then(() =&gt; {
    app.listen(DotEnvConsts.getAppPort(), () =&gt; {
        LoggerLib.debug(`Start on port ${DotEnvConsts.getAppPort()}.`)
        // Event Lisntenerを起動
        new ProjectReportEventListener()
    })
})
</code></pre>
<h1>まとめ</h1>
<p>今回はNode.jsとTypescriptを使って実装する方法を書きました。</p>
<p>TypescriptはkotlinやScaleなどと比較すると型システムとして足りない機能などありますが、ジェネリクスなどをうまく使うことでやりたいことを達成することができます。</p>


Node.jsとTypescriptでドメインイベントを実装する

<p>Another works CTOの塩原です。<br>
フロントエンドの設計は複業クラウドでもいろんなことを試しました。<br>
今回は、現在の複業クラウドのフロントエンド設計を紹介できればと思います。</p>
<h1>技術スタック</h1>
<ul>
<li>Next.js</li>
<li>React</li>
<li>Typescript</li>
</ul>
<h1>フロントエンド設計の考え方</h1>
<h2>1. 無理な共通化・抽象化を行わない</h2>
<p>これは過去の経験からですが、一時期フロントエンドの設計に対して、DDDの考え方や、クリーンアーキテクチャの考え方を取り入れようとしたことがありました。<br>
バックエンドではDDDやクリーンアーキテクチャを導入しているのでフロントエンドでもその考え方を取り入れてみようという考えでした。<br>
複業クラウドのコアな概念をドメインモデルとして定義したのですが、フロントエンドの場合<br>
表示する画面によってデータ構造が影響を受けてしまい、<br>
例えば複業クラウドでも「求人」という概念が一覧画面で見た時と、詳細ページで見た時、閲覧履歴や検索結果から見る時で表示される情報が変わるので共通化や抽象化に苦戦しました。<br>
画面も頻繁に書き変わることが多かったので開発コストと見合わなくなりました。<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/00c6d221-daed-45ff-bf0f-d90f87d3b232%2F%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882022-11-2114.05.26.png" alt="スクリーンショット2022-11-2114.05.26.png"></p>
<h2>2. 変更における影響範囲が広くならないことを意識する</h2>
<p>また上記に関連することですが、共通化などをしすぎると画面変更に伴い共通化したもの自体にかなり大きな変更が入り、結果として特定の箇所の画面変更にも関わらず他の画面にも影響が出てしまうといったことも発生しました。</p>
<p>特に複業クラウドでは大幅に画面仕様が変わることも多く、そういったフェーズでは特に抽象化したものがそもそも0から書き直さなければならないといったことが発生しました。</p>
<h2>3. 仕組み化に頼りすぎずコミュニケーションを重要視する</h2>
<p>エンジニアには自動化や仕組み化といったことが得意かつ好きな人が多く、ついつい全てを仕組み化してしまいたくなりますが、プロダクトチームで人数がまだ10人に満たない中、常に変化も大きいため、仕組み化や自動化は取り入れながらもコミュニケーションを取ることも重要視するようにしています。</p>
<h1>推奨利用しているライブラリ</h1>
<ul>
<li>styled-component
<ul>
<li>reactでcssを書くためのライブラリ</li>
<li>jsx, tsxファイル内で書くことができる
<ul>
<li>css in js</li>
</ul>
</li>
<li>値に応じて動的にCSSを変更するようなコードを書ける</li>
<li><a href="https://styled-components.com/">https://styled-components.com/</a></li>
</ul>
</li>
<li>SWR
<ul>
<li>stale-while-revalidateをうまくやってくれる
<ul>
<li>キャッシュから値を返したあと、裏側で再フェッチし最新データに置き換える</li>
</ul>
</li>
<li>利用する側がフェッチ処理などを意識することなく、データのように利用することができる</li>
<li><a href="https://swr.vercel.app/">https://swr.vercel.app/</a></li>
</ul>
</li>
<li>react-hook-form
<ul>
<li>フォーム管理ライブラリ</li>
<li>バリデーションの機能も持っている
<ul>
<li>Yupを使わずに書くことができる</li>
</ul>
</li>
<li>以前はformikを使っていたが、内部でrefをうまく活用することで再レンダリングする箇所を最小限に抑えていたりなどパフォーマンス面に優れている</li>
<li><a href="https://react-hook-form.com/">https://react-hook-form.com/</a></li>
</ul>
</li>
</ul>
<h1>ディレクトリー構成</h1>
<h2>ディレクトリーの説明</h2>
<pre><code class="language-markdown">-- src
 |-- adapter
   |-- fcCoreApi
   |-- localstorage
 |-- assets
 |-- exception
 |-- hooks
 |-- features
   |-- projectSearch
   |-- mypage
 |-- lib
   |-- date
 |-- pages
 |-- styles
 |-- ui
   |-- homeland
   |-- origin
</code></pre>
<h2>adapter</h2>
<p>データ通信が発生する部分などの技術的な部分を扱うレイヤーを入れています</p>
<p>API通信についてという項目で詳細に説明しますが、useSWRを使うのはこの層になります</p>
<h2>features</h2>
<p>機能単位で分解しているモジュールです</p>
<p>こちらもfeatureディレクトリーについてという項目で詳細に説明します</p>
<h2>lib</h2>
<p>日付の共通処理や数字の変換処理など普遍的なクラスをこの中に入れています</p>
<p>utilではなくlibとした理由は、複業クラウド以外のプロジェクトで利用されても問題ないものが入るという意味を表すためにlibという名前を使いました</p>
<p>カスタムhook系の処理はhooksディレクトリーに入れるのでこの中には入りません</p>
<h2>hooks</h2>
<p>カスタムhooksの中でfeaturesを跨いで使うような共通処理を置くモジュールです</p>
<p>ファイル名は必ずuseXXXとなります</p>
<h1>Featureディレクトリーについて</h1>
<p>弊社ではfeatureというディレクトリーを使って単数もしくは複数のページをまとめています。</p>
<p>まとめた中に共通となるコンポーネントや、カスタムhooks、型定義や定数などを格納しています。</p>
<pre><code class="language-markdown">|-- features
 |-- projectSearch
   |-- ui
     |-- pages
     |-- origin
   |-- consts
     |-- projectConsts // 求人の型を入れておく
   |-- hooks
</code></pre>
<p>そうすることで、hooksやconstsなどの利用範囲が限定されているので</p>
<p>実際に表示で使う型に合わせて定義することができます。</p>
<p>featureディレクトリーというと、一ページ内での機能単位でディレクトリーを切る場合もありますが、機能単位に微妙に分解しづらいものなども存在するのとページ単位の場合、Next.jsでは <code>pages/</code> ディレクトリーをいじらなければ移行自体はやりやすいのでページ単位を採用しました。</p>
<h2>ESLint</h2>
<p>feature同士が依存するとせっかくディレクトリーを分けた意味がなくなるので、</p>
<p>その依存を防ぐためにeslintを使ってimportの依存関係を制御しています。<br>
https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-restricted-paths.md</p>
<pre><code class="language-json">module.exports = {
  extends: [
    'next',
    'next/core-web-vitals',
    'plugin:import/recommended',
    'plugin:import/typescript',
    'prettier',
  ],
  settings: {
    'import/resolver': {
      typescript: {},
    },
  },
  rules: {
    'import/no-restricted-paths': [
      'error',
      {
        zones: [
          {
            from: './src/features/!(accountDelete)/**/*', // 対象の依存パス
            target: './src/features/accountDelete', // 禁止するパス（正規表現可）
            message: 'features同士で依存することはできません', // エラーメッセージ
          },
        ],
      },
    ],
  },
};
</code></pre>
<h1>コンポーネント設計</h1>
<h2>landscape/homeland/origin</h2>
<p>複業クラウドでは三種類のコンポーネントを使いわけています。</p>
<p>以前はAtomicデザインを適用していたのですが、実際の運用を行う上で分けやすい分け方がいいと思いコンポーネントの種類を見直しました。</p>
<h3>landscape</h3>
<p>ボタンや、formなどの基本的なコンポーネント</p>
<p>複業クラウドでは企業側とタレント側などでフロントエンドリポジトリーが分かれているので</p>
<p>npmライブラリで実装して複数箇所で使えるようにしています。<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/ae80688d-fdbb-4bb0-8d73-cbd958c1c370%2FUntitled.png" alt="Untitled.png"><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/57b24c2a-3634-4037-8d9a-4bee936e00fe%2FUntitled(1).png" alt="Untitled(1).png"></p>
<h3>homeland</h3>
<p>このコンポーネントは上記のコンポーネントほど頻出ではないものの、</p>
<p>求人カードやタレントプロフィール画面などプロダクトのコアになりそうなデザインコンポーネントを定義しています。</p>
<p>そうすることで、変更が入った時にも一箇所を修正すれば変更が反映され、デザインする際にも一貫性が保たれます。</p>
<p>こちらはリポジトリーに直接定義するので、企業側・タレント側それぞれで定義されています。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/76583943-7fa1-4df2-9d00-a8f8774a4ddf%2FUntitled(2).png" alt="Untitled(2).png"></p>
<table>
<thead>
<tr>
<th></th>
<th>landscape</th>
<th>homeland</th>
<th>origin</th>
</tr>
</thead>
<tbody>
<tr>
<td>デザイナーとのコミュニケーション</td>
<td>必要</td>
<td>必要</td>
<td>不要</td>
</tr>
<tr>
<td>ビジネスロジックを持てるかどうか</td>
<td>NG</td>
<td>OK</td>
<td>OK</td>
</tr>
<tr>
<td>実装方法</td>
<td>npmライブラリ</td>
<td>src/ui/homeland配下に実装</td>
<td>src/ui/originもしくは各features配下に定義</td>
</tr>
</tbody>
</table>
<h1>API通信について</h1>
<h2>SWRを使ったAPI通信</h2>
<p>弊社ではAPI通信にswrを利用しています。</p>
<p>swrにはいくつか利点がありますが、特に気に入っているポイントとして</p>
<ul>
<li>キャッシュを簡単に行なってくれる</li>
<li>useEffectとuseStateの乱立を防げる</li>
<li>楽観的更新・定期ポーリング・エラー時の再試行などを簡単に実装できる</li>
</ul>
<p>という点が挙げられます。</p>
<p>特にuseEffectとuseStateの乱立を防げるという点では下記のコードで比較をしてみます</p>
<p><strong>useSwrを使わない場合</strong></p>
<pre><code class="language-tsx">import useSWR from 'swr'

function Profile() {
  const [data, setData] = useState(undefined)
  useEffect(() =&gt; {
     const callback = async () =&gt; {
       const result = await fetcher()
       setData(result)
     }

     callback()
  }, [setData])

  if (!data) return &lt;div&gt;loading...&lt;/div&gt;
  return &lt;div&gt;hello {data.name}!&lt;/div&gt;
}
</code></pre>
<p><strong>useSwrを使う場合</strong></p>
<pre><code class="language-tsx">import useSWR from 'swr'

function Profile() {
  const { data } = useSWR('/api/user', fetcher)

  if (!data) return &lt;div&gt;loading...&lt;/div&gt;
  return &lt;div&gt;hello {data.name}!&lt;/div&gt;
}
</code></pre>
<p>とこのようにSWRを使わない場合、useEffectとuseStateを駆使しなければいけません。</p>
<p>APIが一つなのでまだシンプルですが複数必要になるとかなり複雑になってきます。</p>
<h2>SWRを使った設計</h2>
<p>上記のサンプルコードはSWRの公式ドキュメントを参考にしたものなので、</p>
<p>コンポーネント内に直接 <code>useSWR</code> を記載していますが、</p>
<p>このような書き方にはいくつか問題があると考えています。</p>
<ul>
<li>異なるデータのキャッシュの値が被ってしまう可能性がある
<ul>
<li>APIのパスにすれば被っても問題ない
<ul>
<li>postやgetのrequest情報もパスに含める想定なら
<ul>
<li>ただ理想としてはキャッシュ値は中央集権的に管理しておきたい</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>第二引数のデータ構造をAPIのまま使うのではなく、加工したいときにコンポーネントに加工処理が漏れる</li>
<li>APIのレスポンスやリクエスト内容などはコンポーネントの関心ごとからは切り離したい
<ul>
<li>これはプロダクトの思想によっては異なる</li>
</ul>
</li>
</ul>
<p>そのため複業クラウドでは以下のような三層構造で設計をしています</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/8093264e-df13-4d23-a307-088e4c204ef6%2F%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882022-12-0516.04.04(1).png" alt="スクリーンショット2022-12-0516.04.04(1).png"></p>
<p>Adapter層では、APIと直接通信し、APIのエンドポイントごとに通信するための関数を用意し、その中でSWRを実行しています。</p>
<p>feature内のhooksで、adapter層の関数を使って、見た目に必要な情報などを加工する処理などを記載します。</p>
<p>楽観的更新やポーリングなどもこのcustom hooksで実装するようにしています。</p>
<p>componentはAdapterを直接参照せずに、feature内のhooksから参照するようにすることで、componentがそこまでAPIの情報を意識することなく利用することができます。</p>
<p><code>adapter/useGetProfile.ts</code></p>
<pre><code class="language-tsx">export function useGetProfile(request: {id: string}) {
  const { data, error } = useSWR(['/api/user', request], fetcher)
  return data, error
}
</code></pre>
<p><code>feature/hooks/useProfile.ts</code></p>
<pre><code class="language-tsx">export function useProfile(params: {id: string}) {
  const {data, error} = useGetProfile(params)
  return {
    data: {
      ...data,
      fullname: data.lastName + data.firstName
    },
    loading: !error &amp;&amp; !data
  }
}
</code></pre>
<p><code>feature/ui/origin/profileBox.tsx</code></p>
<pre><code class="language-tsx">function ProfileBox() {
  const { data, loading } = useProfile()
  
  if (loading) return &lt;div&gt;loading...&lt;/div&gt;
  return &lt;div&gt;hello {data.fullname}!&lt;/div&gt;
}
</code></pre>
<h1>まとめ</h1>
<p>フロントエンドに限らず設計は日々最適解を見つけながら進化させていくべきだと考えています。<br>
なので今回の設計で満足せずに、会社の規模・チームの規模、技術の進歩に合わせて常に改善を続けていきたいと考えています。</p>


複業クラウドのフロントエンド設計を紹介します！

<h2>はじめに</h2>
<p>こんにちは。nonoyamalfoyです。<br>
弊社ではwebをnext.js, アプリをreact-nativeで開発しています。<br>
フロントエンドアーキテクチャので最近流行りのfeaturesアーキテクチャについての見解を述べようと思います。</p>
<h2>featuresとは</h2>
<p>超簡単にいうと、機能ごとにUIやロジックを隠蔽していくディレクトリ構造。</p>
<pre><code class="language-jsx">features
   ├── message（メッセージ機能）
   │    ├── hooks/
   │    ├── types/
   │    └──  ui
   │         ├── origin/
   │         └── pages/
   ├── profile/（プロフィール機能）
   └── signin/（サインイン機能）
</code></pre>
<h2>React公式の見解</h2>
<p>React は、ファイルをフォルダーに入れる方法について意見を持っていませんが、以下の２つを例として上げています。</p>
<ul>
<li>機能またはルートによるグループ化<br>
「機能」の定義は普遍的なものではなく、粒度を選択するのはユーザー次第とのこと。<br>
featuresなどはこちらに分類されます。</li>
</ul>
<pre><code class="language-ts">message/
    index.ts
    messageApi.ts
    message.tsx
    message.css
    message.story.tsx
    message.test.ts
profile/
    index.ts
    profileApi.ts
    profile.tsx
    profile.css
    profile.story.tsx
    profile.test.ts
</code></pre>
<ul>
<li>同様のファイルをグループ化<br>
Atomicデザインなどはこちらに分類される。</li>
</ul>
<pre><code class="language-ts">api/
    messageApi.ts
    profileApi.ts
components/
    profile.tsx
    profile.css
    profile.story.tsx
    profile.test.ts
    message.tsx
    message.css
    message.story.tsx
    message.test.ts
</code></pre>
<p><a href="https://reactjs.org/docs/faq-structure.html">File Structure - React</a></p>
<h2>複業クラウドの例</h2>
<h3>初期の頃の構成</h3>
<p>リリース初期は同様のファイルをグループ化する形をとっていました。</p>
<ul>
<li>componentsやhooksの肥大化が発生。</li>
<li>componentsディレクトリに切り分けたコンポーネントを入れていくので、抽象的な名前をつけてしまうと名前が被ることがあり後々後悔することになる。</li>
<li>該当のコンポーネントがどこにあるのか、どこで使われているのかがわかりにくい</li>
</ul>
<pre><code class="language-jsx">src
├── components（ドメインロジックのない汎用的なコンポーネント）
│      ├── atoms/（最小の粒度、TextAtom, IconAtomなど）
│      ├── molecules/（atomの集合体、基本的に複数箇所で利用される）
│      └── organisms/（atom,moleculesの集合体、複数箇所で利用されない場合もある）
├── windows
│      ├── components/（ドメインロジックのあるコンポーネント、ページの肥大化、コンポーネントの共通化を目的に切り分けたものを格納）
│      ├── member/
│      ├── public/
│      └── route/(ルーティング)
├── lib/
├── models/
├── modules/(サーバーとの接続)
└── hooks/
</code></pre>
<h3>2023年1月現在</h3>
<p>features内でhooksやuiを分けることで機能ごとの依存を防ぐようにしました。</p>
<pre><code class="language-jsx">src
├── features
│      ├── message（メッセージ機能）
│      │           ├── hooks/
│ 	  │           ├── types/
│      │           └──  ui
│      │                 ├── origin/
│      │                 └── pages/
│      ├── profile/（プロフィール機能）
│      └── signin/（サインイン機能）
├── ui
│    ├── origin
│    └── homeland
├── adapter/(サーバーとの接続,apiを叩いてデータを返す)
└── lib/(汎用的なロジック)
</code></pre>
<h2>featuresアーキテクチャの特徴</h2>
<ul>
<li>機能単位ごとに疎結合にできる（これが一番大きいメリットだと感じています。）
<ul>
<li>機能単位で改善することが多いので不要なデグレを避けることができる</li>
<li>機能削除する際にディレクトリごと消せばいい</li>
</ul>
</li>
<li>featuresディレクトリを見ると、プロダクトにどんな機能が存在するのかわかる</li>
<li>機能を意識した実装や見積もりを行うことができる
<ul>
<li>機能によってはUIから作成したい場合、ロジックから作成したい場合、型から実装したい場合などいろいろなケースがあるかと思います。</li>
</ul>
</li>
<li>コンポーネントの命名に迷うことが減る。</li>
<li>ドメインを意識した開発を行える。</li>
</ul>
<p>下記でもう少し詳しく解説します。</p>
<h2>機能単位ごとに疎結合にできる</h2>
<p>プロダクト開発は機能単位で改善、削除することが多いです。<br>
そのため、他のfeatures同士で依存しないよう意識すれば編集を入れても他の機能への影響が出にくくなります。<br>
また、機能削除する際にディレクトリごと消せばいいので楽になります。</p>
<h2>プロダクトにどんな機能が存在するのかすぐにわかる</h2>
<p>以下のようにfeaturesを見ればmessege, profile, signinの機能があることがすぐにわかります</p>
<pre><code class="language-jsx">features
   ├── message（メッセージ機能）
   │    ├── hooks/
   │    ├── types/
   │    └──  ui
   │         ├── origin/
   │         └── pages/
   ├── profile/（プロフィール機能）
   └── signin/（サインイン機能）
</code></pre>
<h2>ドメインを意識した開発がしやすい</h2>
<p>featuresアーキテクチャでは機能ごとにUIとロジックを隠蔽できるため、ロジックから作成する。型から作成する。といった機能に焦点を当てた開発がとてもしやすいメリットがあります。</p>
<h2>コンポーネントの命名に迷うことが減る。</h2>
<p>機能ごとにファイルを隠蔽できるため、別の機能とコンポーネント名がかぶっても問題がない。<br>
例えば機能やページごとに異なる「Header」が存在した場合、「~Header」みたいにする必要はなく「Header」という名前で実装できる。</p>
<h3>Tips</h3>
<p>feature同士の依存を強制的に防ぐために、eslintを利用できます。</p>
<pre><code class="language-json">rules: {
    'import/no-restricted-paths': [
      'error',
      {
        zones: [
	//profile feature以外でtargetのpathをインポートできないように
          {
            from: './src/features/!(profile)/**/*', // 対象の依存パス 
            target: './src/features/profile', // 禁止するパス
            message: 'features同士で依存することはできません',// エラーメッセージ
          },
	 //message feature以外でtargetのpathをインポートできないように
          {
            from: './src/features/!(message)/**/*', // 対象の依存パス
            target: './src/features/message', // 禁止するパス
            message: 'features同士で依存することはできません', // エラーメッセージ
          },
        ],
      },
    ],
  },
</code></pre>
<h2>最後に</h2>
<p>featuresアーキテクチャのメリットをいくつか紹介しましたが、機能の少ないプロダクトやリリース初期のプロダクトは「同様のファイルをグループ化」するほうがいいと思っています。<br>
機能が少ない場合はむしろfeaturesの肥大化が起きたり、どの粒度の機能で切るのか悩む時間が発生します。<br>
機能が増えてディレクトリが肥大化してきたタイミングでfeaturesアーキテクチャの導入を検討するのがいいと思います。</p>
<p>「弊社プロダクトの設計をもっと知りたい！」と思った方は以下を合わせてお読みいただけると幸いです。<br>
<a href="https://tech.anotherworks.co.jp/article/frontend-architecture-for-react">複業クラウドのフロントエンド設計</a></p>
<h2>参考文献</h2>
<p><a href="https://dev.to/profydev/screaming-architecture-evolution-of-a-react-folder-structure-4g25#discussion-of-the-featuredriven-folder-structure">Screaming Architecture - Evolution of a React folder structure</a></p>
<p><a href="https://zenn.dev/meijin/articles/bulletproof-react-is-best-architecture">Reactベストプラクティスの宝庫！「bulletproof-react」が勉強になりすぎる件</a></p>
<p><a href="https://zenn.dev/yodaka/articles/eca2d4bf552aeb">Next.jsディレクトリ構成・設計再考（featuresが何を解決するか）</a></p>
<p><a href="https://ja.reactjs.org/docs/faq-structure.html">ファイル構成 - React</a></p>


#Architecture

BigQueryのビューでDWHを作る

Node.jsとTypescriptでドメインイベントを実装する

複業クラウドのフロントエンド設計を紹介します！

Reactのディレクトリ構成にfeaturesを導入してみた