はじめに Clean Architectureやレイヤードアーキテクチャでは、どのようにレイヤーを定義するかついては言及されています。 そのような中usecase(レイヤードアーキテクチャではApplication層)をどのように実装するべきかについての議論は少ないです。 しかし私はリーダブルなアーキテクチャを実現するために、一番大切なことはusecaseを適切に実装することであると考えています。 そこでusecaseを実装する上で起こりがちな抽象度の問題を例に、リーダブルなアーキテクチャを考えいていきたいと思います。 サンプル 1:1のチャットアプリでUserとWorkerが存在して会話ができるアプリを例にあげます。 以下の図では青い背景はinfraの関数実行、緑色の背景はdomainの関数実行、赤い背景はusecaseの関数実行を示しています。 usecaseのCreateChat関数

はじめに Goの良いところは、最低限の文法を知っていればコードを上から順番に読むことで詳細を容易に理解できることです。 文法の中にシンタックスシュガーや特別な省略が許されていないため多様な表現になることはありません。 そのためGoを書ければGoの本体と標準ライブラリを読むことができます。 しかし以下の原因により、これらの利点を守ることが難しくなることがあります。 DSL フレームワーク 抽象化 これらは設計として新たな制約を課すことで品質向上や実装を容易にするためのものです。 またこれらを採用する論理立てた 正しい 理由が存在します。 DSL DSLを提供するツールとして、DIのための wire があります。 GoでDIを実現するためには多くの実装を必要とするため、実装量を減らすためにもDIツールが求められてきました。 これは 正しい です。 しかし一方でDSLはコードを読む人間に言語以上

はじめに 近年Web技術は様々な選択肢が存在しています。その中でユースケースに応じて適切に技術選択することがプロダクトのためにはとても大切です。 エンジニアの興味関心だけで不要な技術選択をして、開発速度やユーザ体験の低下は起きていないでしょうか？ また技術選択をするときに正しい言語化をできているでしょうか？ コンポーネント開発をしたいから、Reduxを採用する SPAにしたいから、Reduxを採用する 単一フローを採用したいから、Reduxを採用する React Hooksの登場でReduxは必要なくなった これらはすべて適切な説明ではありません。 今回は、React、SPA、Flux、Reduxをそれぞれ採用している方が、改めてその技術選択をしていることを言語化できているかの確認になればと思います。 Reactを採用するべきか？ Reactの価値は宣言的UI、コンポーネント開発にあります