フロントエンドの複雑さに立ち向かう / Tackling Complexity of Front-end Software with DDD and Clean Architecture
フロントエンドの複雑さに立ち向かう 〜 DDD と Clean Architecture を携えて 〜 さくらのテックランチvol.6 〜ローストチキンのフロントエンドパスタとクリスマスFigmaケーキ〜 https://sakura-tokyo.connpass.com/event/303232/ YouTube配信アーカイブ https://www.youtube.com/watch?v=usmLmI1bj74&t=472s ドメイン駆動設計（Domain-Driven Design）や Clean Architecture をヨイショもディスもせずフラットな立場で評価し、現実解を探りながらフロントエンドの複雑さに立ち向かった半年間の軌跡
フロントエンドの複雑さに立ち向かう 〜DDDとClean Architectureを携えて〜 | さくらのナレッジ
自己紹介 さくらインターネットではシニアフロントエンドエンジニアをやっています。代表作は「NES.css」というファミコン風CSSフレームワークで、エイプリルフールには「さくらのINFRA WARS」というゲームの企画開発をしていました。 話さないこと 本記事ではソフトウェア設計ということで、以下の設計・アーキテクチャに関しては話す予定はありません。コンポーネント設計や CSS 設計に関しては過去に記事やスライドを公開していますので、気になる方はそちらを参考にしていただければと思います。 コンポーネント設計 加速するコンポーネント設計入門 / Component Design as an Accelerator コンポーネント指向時代のmargin戦略 / Rethinking the relationship between Components and Margins CSS設計 OO
はじめに 最近個人開発でよくPythonを使ってるのですが、仕事でも使うようになり、そろそろ開発環境を真面目に構築しようと思い、色々調べたのでご紹介しようと思います 構成 今回は以下のパッケージを使用しました パッケージ管理＋仮装環境 rye Linter ruff 静的型チェック mypy rye ちなみに業務の方ではryeではなく、poetry+venv(pyenv)の構成で使っています 一応公式には実験的プロジェクトでプロダクトでの利用は不向きと判断したからです Rye は、Rust の Rustup と Cargo からインスピレーションを得て、Python に新しいタイプのパッケージング エクスペリエンスを構築する実験的な取り組みです。まだ製品化の準備ができていませんが、フィードバックや提案をいただければ幸いです。 まずはryeをダウンロードします 公式サイトの通りに進めます r
はじめに CyberAgentのインターンで触れたアーキテクチャである、Flux, Clean Architectureについての個人的な見解を述べるだけです 「アーキテクチャはこうあるべき」みたいな原理主義的な話はしません この記事で書くこと Fluxの特徴 Clean Architectureの特徴 MVVM × Clean Architecture Fluxの特徴 FluxはFacebook社が作成したアーキテクチャパターンで、もともとはJSで使われていたものです。 各要素の役割として以下の通りです。 Dispatcher: 発火されたActionをStoreに通知するもの Action: Viewなどから発火されたEventをDispatcherに通知するもの Store: Dispatcher経由できたActionに応じて、データを管理するもの View: StoreのデータをU
2022年版実践WPF業務アプリケーションのアーキテクチャ【設計編／前編】 ～ドメイン駆動設計＆Clean Architectureとともに～
設計編の構成 前述の構成は、アーキテクチャ設計書としては読みやすいと思います。しかし実際にアーキテクチャ設計を行っていく場合、各ビューを頻繁に行ったり来たりしながら記述します。いずれかを先に完璧に書きあげるという訳には行きません。 たとえば論理ビューから実装ビュー・配置ビューは概ねその方向に流れて設計しますが、論理ビュー自体がユースケースビューや非機能要件ビューの設計に伴い頻繁に更新されるため、ウォーターフォール的な流れにはならず、インクリメンタルなプロセスになります。 本稿では「アーキテクチャ設計書はこうなります」という設計結果をお見せするのではなく、どのようにアーキテクチャを設計していくか解説したいと考えています。そのため設計書としてのアーキテクチャ設計とは、やや異なったアプローチで記載します。 そこで設計編では、次の構成で記載していきたいと思います。 前編 初期ドメインビューの設計
SwiftUI + Combine で MVVM & Clean Architecture な設計を考えてみた - Qiita
はじめに こんにちは。 iOS 13 で SwiftUI がリリースされてから早 2 年。 そろそろ SwiftUI をちゃんと学んでおこうと思い立ち、趣味プロダクトで SwiftUI の習作アプリを開発してみました。 出来上がったもの 小説投稿サイト 小説家になろう の公開 API を利用させていただき、該当サイトの閲覧アプリを開発しました。 動作イメージ 実装した機能 「日間」「週間」「月間」「四半期」の小説ランキング閲覧機能 小説の検索機能 小説の閲覧機能（ただの WebView ですが。。。） 実際のコード 以下のリポジトリに置いてあります。もし興味がありましたら是非触ってみてください。 https://github.com/inokinn/NaroViewer アーキテクチャについて SwiftUI を使ってみるにあたり、まず悩んだのはアーキテクチャの選定でした。 SwiftUI
ソフトウェアの振る舞いは、拡張できるようにすべきである こちらは「オープン・クローズドの原則」に関する記述です。 ソフトウェアの振る舞いは、既存の成果物を変更せず拡張できるようにすべきである、ということだ。 これこそが、我々がソフトウェアアーキテクチャを学ぶ根本的な理由だ。 ちょっとした拡張のために大量の書き換えが必要になるようなら、そのソフトウェアシステムのアーキテクトは大失敗への道を進んでいることになる。 拡張可能な設計！ 肝に銘じます！ インターフェイスは分離させよ こちらは「インターフェイス分離の原則」に関する記述です。 必要としないモジュールに依存することは一般的に有害とされる。 ソースコードの依存関係においては、再コンパイルや再デプロイを強制されるので明らかに有害であることがわかる。 だが、さらに上位のアーキテクチャレベルにおいても有害なのだ。 この辺りは今どきのフレームワーク
「Clean Architecture」の学習記録。 「第Ⅲ部 設計の原則」のまとめ。 SOLID原則の目的 SOLID原則の概要 クリーンなコードを書く原則として「SOLID原則」がある。 これは関数やデータ構造をどのようにクラスに組み込むか、そしてクラスの相互接続をどのようにするのかを教えてくれる。 SOLID原則の目的 SOLID原則の目的は以下のような性質を持つ中間レベルのソフトウェア構造を作ることである。 - 変更に強いこと - 理解しやすいこと - コンポーネントの基盤として、多くのソフトウェアシステムで利用できること 「中間レベル」とはモジュールレベルの開発に使われることを意図している。 つまりコードレベルよりも上のレベルに適用するものであり、モジュールやコンポーネントで使うソフトウェア構造の定義に役立つものである。 SOLID原則の概要 単一責任の原則（SRP: Singl
当たり前ではあるが、継続的にプロダクトを開発し続けるためには、継続的にプロダクトを開発し続けられるソフトウェアを維持する必要がある。 なので、継続的にプロダクトを開発し続けられるソフトウェアにするには、どうすればよいのかを理解しておく必要がある。 また、”スピードを優先する”的な発言が多々あると思うが、意図的に優先するためには、優先しない場合を理解し実践できる必要があると思われる。（意図的に負債をためている） 仮に、”優先しない場合を理解し実践できない”状態で”スピードを優先する”を行うと、”とりあえず動くが継続的に開発し続けられない”状態になるスピードも暗黙的に早めていると思われる。（意図せず負債をためている） で、”とりあえず動くが継続的に開発し続けられない”状態になってしまったと仮定して、なんとか”継続的に開発し続けられる”状態に持っていきたい場合を想定する。 その状態に持っていくた
なんらかのアプリケーションを書いていて悩むはずであろう普遍的なトピックなのかと思っていたが、スタンダードなソリューションはなかった。 ある程度世に出ているものを羅列していこうと思う。 筆者の見立てでは、変更の原子性に関してもusecase層（あるいはservice層、つまりソフトウェアの機能要件を満たす振る舞いを表現する層）で書くべきだと考えている。 これが表現されていないと、usecase層で表現されたデータ変更の原子性が担保されていなくても良いように認識されてしまう。Design Docなどのドキュメントで前提を補うことはできたとしても、可能な限り仕様に関しては見えるべきところで明確に表現するべきだ。
はじめに 私はこれまでいかにPureScriptでClean Architectureを実現するか模索し続けてきたわけですが、また新しい方法を考えたので紹介したいと思います。 この記事の構成 この記事は大きく3つのセクションに分かれています。 それなりに長い記事となっておりますので、目的に応じて目次から興味のあるところまで飛んでいただけたらと思います。 私がこの記事で紹介する手法にたどり着くまでの流れ 具体的にどうやってTagless FinalでClean Architectureを実現するのかの説明 この手法を用いて私が作った4層の小さなサンプルアプリケーションのコードを見る 説明しないこと 文章量が長くなりすぎるため、以下の説明は割愛させてください。 Tagless Finalについての詳細な解説(簡単に説明はします) Clean Architectureについての解説 PureSc
『Clean Architecture 達人に学ぶソフトウェアの構造と設計』は、オブジェクト指向プログラミング、アジャイル開発の第一人者であるボブおじさん。Robert C. Martin の著作だ。長年の経験をもとに良いアーキテクチャに共通する設計原則を解説した本である。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘 ドワンゴ Amazon 一時期あの謎円が話題になったこともあり、ソフトウェア開発に関わる人なら１度は耳にした本だろう。クリーンアーキテクチャというキャッチーな言葉だけが独り歩きしてるが、本書を薦めるソフトウェアエンジニアは多い。 では、少しだけ本書の内容を紹介しよう。 アーキテクチャの原則 本書で紹介される設計原則は、有名なSOLID原則と非循環依存の原則、安定依存
【読書ノート】Clean Architecture 達人に学ぶソフトウェアの構造と設計 - TadaoYamaokaの開発日記
書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだので、内容をまとめた。 以下の内容は、ほとんどClaude3 Opusを使用して作成している。 まえがき・第I部 イントロダクション まえがき ソフトウェアシステムの構造を決定するルールは、システムの種類に関係なく普遍的である。ソフトウェアアーキテクチャの目的は、システム構築に必要な人材を最小限に抑えることであり、設計の品質は開発・保守に必要な労力で測ることができる。アーキテクチャは仮説であり、実装と計測によって証明すべきものである。本書は、時代を超越した不変のルールを解説する。 印象的なフレーズ 恋のおそろしい化け物とは、意欲は無限だが実行は有限、欲する心ははてしないがおこなうには限度がある。 優れたアーキテクチャのコストが高いと思うなら、劣ったアーキテクチャにすればいい。 速く進む唯一の方法は、うま
clean-architectureのcontroller層でwebフレームワーク固有の実装をしたくない - Qiita
labstack/echoなどを用いて開発をする際、公式サンプルのように、query, path, jsonをバインドする処理や、レスポンスを行う処理がecho.Contextに強く依存しています。 このwebフレームワーク独自の実装をclean-architectureで言うところのweb層に隠蔽できないかと言うことでトライしてみました。↓結果 前提：ここでのclean-architectureの解釈 webでhttpリクエストを受け付け、パス情報をもとにcontrollerを呼び出す controllerでリクエスト時のパラメータを解釈しusecaseを呼び出す usecaseで処理した結果をpresenterに渡す presenterでレスポンス用の形に変換 webでhttpリクエストに対するレスポンスを返却する echo.Contextの取り扱い 上記前提を実現するにはecho.C
はじめに Clean Architecture とは DB やフレームワークなどの外部技術に依存せず、ソフトウェアの中核部分（ビジネスを表現する部分）の独立性を高めることで、外部技術の変更に強いソフトウェアを実現することを目的とする。 以下は Clean Architecture の概念図です。図を見ながらポイントを解説していきます。 「関心事の分離」を目的としたアーキテクチャ ソフトウェアをレイヤーに分割。各レイヤーの責務を明確にし、レイヤー間の依存関係を制限することで、関心事を分離する データベースとの連携を責務とするレイヤー、API 通信を責務とするレイヤー、ビジネスロジックを責務とするレイヤーなど 関心事が分離されることで、他レイヤーの変更による影響を最小限にし、変更に強いアーキテクチャを実現する 4 つのレイヤーで構成される（4 つである必要はない。依存方向のルールを遵守する事が
内容紹介（出版社より） 書いているコードが変わらないのだから、どんな種類のシステムでもソフトウェアアーキテクチャのルールは同じ。ソフトウェアアーキテクチャのルールとは、プログラムの構成要素をどのように組み立てるかのルールである。構成要素は普遍的で変わらないのだから、それらを組み立てるルールもまた、普遍的で変わらないのである。（本書「序文」より） 目次（「BOOK」データベースより） 第１部 イントロダクション／第２部 構成要素から始めよ：プログラミングパラダイム／第３部 設計の原則／第４部 コンポーネントの原則／第５部 アーキテクチャ／第６部 詳細／第７部 付録
chatGPTに聞いたら一瞬でclean architectureを完全に理解したので会話を共有します。 Clean Architectureについての会話 私: Clean Architectureについて理解したいので手伝ってください。 まず、簡単に3行でClean Architectureについて説明してください。 ChatGPT: Clean Architectureは、ソフトウェア設計の一種で、システムのメンテナンス性と拡張性を向上させるために設計されています。このアーキテクチャは、依存関係のルールに従い、各層が独立して機能するように層を明確に分けます。その結果、コードの再利用が容易になり、テストやデバッグもシンプルになります。 私: どういう層に分けるのですか？ ChatGPT: Clean Architectureでは、ソフトウェアを以下のような層に分けます： エンティティ層
Clean Architecture (aka Onion, Hexagonal, Ports-and-Adapters) organizes your code in a way that limits its dependencies on infrastructure concerns. This resu...
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Pythonの開発環境を一新した - Clean Architecture, Clean Life
FluxとClean Architectureについて比較して考えてみた - Qiita
「Clean Architecture（クリーンアーキテクチャ）」の内容をまとめました - Qiita
【Clean Architecture】第Ⅲ部 SOLID原則 - kyonc5’s diary
"The Clean Architecture" から学ぶ "抽象に依存する"
Clean ArchitectureでDBのTransactionをどう表現するか？
PureScriptでClean Architecture - Tagless Final編
変わることのない『Clean Architecture』の原則 - Think Wild
Go で Clean Architecture 入門 - Qiita
Clean Architecture 達人に学ぶソフトウェアの構造と設計
chatGPTに聞いたら一瞬でclean architectureを完全に理解したので会話を共有します。
Clean Architecture with ASP.NET Core 8 | .NET Conf 2023