■ クリーンアーキテクチャって難しい。 クリーンアーキテクチャって難しいですよね。 この有名な同心円状の図、何度見てもよくわかりません。右下にある矢印もよくわかりません。 様々な記事を見ても、やっぱり分かるような分からないような... プロダクトに COM 通信が必要になったので勇んでクリーンアーキテクチャを採用したはいいものの、 どうにも理解しきれず泣きながら必死に試行錯誤をしていたところ、 ふと クリーンアーキテクチャは『鎖国』に例えると分かりやすい という事に気が付きました。 本記事では初心者なりにその言語化にチャレンジしてみたいと思います。 ※ なお考え方そのものに着目するため、コードは全く取り扱いません。その点ご了承ください。 またクリーンアーキテクチャは、表面的なメリット(ユニットテストしやすい等) だけを見て批判されてしまうことも有るようです。 その辺りについても少し触れてみ
こんにちは。 京都開発拠点でGoエンジニアをしています @yoskeoka です。 Goを中心技術として性能改善やプロダクト間を横断するような機能の設計、実装を行うKTAチーム (京都開発本部 テクニカルアーキテクトチーム) 所属です。 突然ですが、皆さんはGoでテストを書いているでしょうか。 我々はテストを書くことが中長期的なスピードアップに繋がると信じて日々テストを書くようにしています。 KTAではGoの実装をする際にClean Architectureの考えに基づいたpackage分けを行っていますが、packageを分けたり、インターフェースを定義したりとしていくと、テストを書くのが難しい部分というのが出てきます。 そんな場合に使えるモック作りテクニックを今回は紹介したいと思います。 Clean Architectureはテストしやすくなると言うが Clean Architectu
Next.js（App router）における開発しやすいディレクトリ構成の例 - TechDoctor開発者Blog
初めまして、テックドクターでフロントエンド開発を担当している大瀧です。 ディレクトリ構成はコードの可読性やスケーラビリティに関わる重要な要素であると思っています。 しかし、フロントエンドのディレクトリ構成はベストプラクティスが確立されておらず、わりと悩むポイントです。 そこで今回は、Next.jsのApp routerにおいて、弊社で採用しているディレクトリ構成を共有します。この記事がディレクトリ構成に悩む開発者の助けになれば幸いです。 ディレクトリ構成の自由度が高すぎる問題 さきほど「フロントエンドのディレクトリ構成はベストプラクティスが確立されていない」と書きましたが、特にApp routerのディレクトリ構成については、公式ドキュメントで以下のように記載されています。 There is no "right" or "wrong" way when it comes to organi
Clean Architectureを採用したBackend For Frontendの開発とこれまでの所感 - LIFULL Creators Blog
こんにちは。テクノロジー本部のyoshikawaです。好きなLinux DistributionはManjaro Linuxです。 今回はレガシー化が進むLIFULLのメインサービスの開発効率の向上とコードベースの健全性の確保をすべく、Clean Architectureを採用しバックエンドを刷新している取り組みについて紹介させていただきます。 なお、Clean Architecture自体の説明および解説は本記事では行いません。 背景：歴史あるバックエンドの刷新 アプローチ：新たなアーキテクチャと共創 採用したアーキテクチャ・技術 Clean Architectureを採用した理由 TypeScriptを採用した理由 LoopBackを採用した理由 Clean Architectureの実践 レイヤー分け：例の図と新BFFアーキテクチャのレイヤーとのマッピング レイヤー内・レイヤー間：独
Alex Bespoyasov Posted on Sep 1, 2021 • Updated on May 12, 2022 • Originally published at bespoyasov.me Not very long ago I gave a talk about the clean architecture on frontend. In this post I'm outlining that talk and expanding it a bit. I'll put links here to all sorts of useful stuff that will come in handy as you read: The Public Talk Slides for the Talk The source code for the application we'
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2022 、10日目の記事です。 これはなに？ ろくに設計せずにシステム開発を進めると技術的負債が蓄積し、変更が難しくなってしまいます。 しかし設計を推進しようにも、周囲が設計is何を知らないと、なかなか理解を得られません。特にビジネス側や経営側はプログラムの内部構造を知らないわけですから、輪をかけて説得が困難です。 この記事は、ビジネス側や経営側など、非エンジニアサイドに対して技術的負債や設計を分かりやすく説明するための例えや手法をまとめたものです。 私が非エンジニアサイドへ説明するとき実際に活用しているもので、聞き手からも「分かりやすい」と好評を得ております。 この記事のゴール 以下を知ることがこの記事のゴールです。 技術的負債や設計について、非エンジニアサイドに理解を促すノウハウ ユ
はじめに CX事業本部の佐藤智樹です。 今回は先月中頃に実施したLambdaのテスト領域に関する技術共有会の資料と当日にいただいた意見を紹介します。技術共有会自体はお客様含め5人ほどで実施予定でしたが、社内の方を誘ったところ15人程と大人数でディスカッションしながら知識を深めました。有意義な時間となったのでブログで共有します。 本記事はLambdaに対してどのようなテストをすべきか、Lambdaでこれからテストを書くがどうやれば良いか悩んでいる方などは参考になるかと思います。いくつか紹介するテストパターンのメリット/デメリットもあげるので、テスト選定の上で参考にしてください。 例となる題材がなければ抽象的な話ばかりになり分かりづらくなるので、今回は以下のIoTデータ収集システムをベースにどうテストを書いていくか検討します。IoTデバイスからきたデータをRDSに保存するシステムです。色々書い
【Unit4 ブログリレー6日目】 こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 最近まで開発していたm3ラウンジでは、goからRDBを利用していました。 m3ラウンジでは、SQLの組みやすさやテストのしやすさの観点で検討した結果、goquを採用しましたので、 そこで得られた知見とその実装例を紹介します。 これから試してみる方(と将来m3ラウンジの開発に新たに入ることになったメンバー)の参考になるように、サンプルコードも説明も多くなってしまいかなり長いです。 お時間ある時にお読みいただければ。 名古屋城は、日本の城のひとつ。尾張国愛知郡名古屋（現在の愛知県名古屋市中区本丸・北区名城）にある。本文には特に関係ありません。 m3ラウンジ goqu 実例 modelの構造体 mapper mapperの実装 goquのSQLの結果から構造体へのマッピング
SOLID原則をまとめてみた Part1 ～SOLID原則とはなんぞや編～ - ecbeing labs（イーシービーイング・ラボ）
はじめに SOLID原則とは どうしてSOLID原則が生まれたのか ダメなソフトウェア設計の4つの原因 Rigidity-剛性 Fragility-脆弱性 Immobility-不動性 Viscosity-粘性 本当の原因 どんな変更が設計をダメにするのか おわりに&次回記事に続く… はじめに はじめましてorこんにちは！ ecbeing2年目、R&D部門所属のいかちゃんです。 これまでは、Dockerの記事やスクラムに関する所感記事、JavaScriptライブラリに関する記事を書きました。 blog.ecbeing.tech そして今回…というより本シリーズでは、泣く子も黙る『Clean Architecture』本を参考に…。 https://www.amazon.co.jp/dp/B07FSBHS2Vwww.amazon.co.jp ソフトウェア設計の5つの原則として名高い「SOLI
RESTful APIをシュッと作る技術 - PythonとFastAPIでバックエンドを5時間ちょいで作ってみた - Lean Baseball
久々に開発ネタです. 大晦日ハッカソン2019 #大晦日ハッカソンで, 野球のデータをシュッと見るためのDashboardを作る（理由は後ほど）. そんなDashboardのBackend APIをシュッと開発する. を目標に立て現在進行系でやってるのですが, 午後の進捗その2 Docker化が特に滞りなく完了. API Docも見れるとかFast API強すぎぃ 昨日の夕方から開発してたAPIはアッサリ1st Ver.できたので, 大晦日の買い物終わったらフロントエンドを除夜の鐘が鳴るまでになんとかするぞ #大晦日ハッカソン pic.twitter.com/wWMiSvQDKu— Shinichi Nakagawa (@shinyorke) 2019年12月31日 Backendを昨日（12/30）の18:00から着手して（実質作業時間）約5時間ちょいで完成させてしまいました. 本年最後
Firebase をフロントエンドから適切に隠蔽するための「Hooks Injection パターン」 - JX通信社エンジニアブログ
取締役の小笠原(@yamitzky)です。 JX通信社では、React 製のフロントエンドでも Clean Architecture で設計するなど、なるべく特定のバックエンドに依存しない設計を心がけたりもするのですが、一方で Firebase をラップした react-firebase-hooks などの「便利な Hooks」を使って開発スピードを加速したい、という課題を持っていました。 そして先日、次の記事が話題になっていました。まさに「どう Firebase を隠蔽するか」と「どう Firebase を活用するか」を両立する悩みです。 blog.ojisan.io 結論を言うと「Hooks そのものを注入する」のが筋が良いのではないか と思っています。個人的に「Hooks Injection パターン」と名付けたこの方法をご紹介したいと思います。 今回の記事の完成形はソースコードを公
こんにちは、クレスウェア株式会社の奥野賢太郎 ( @okunokentaro ) です。今年もよろしくお願いします。 今回は、Reactでのクリーンアーキテクチャの採用の是非についてTwitterにつぶやいたところ、思いの外Likeが集まったため、まとめて閲覧できるようにツイートをまとめつつ、簡単に補足しようかと思います。 リアクションのもととなった記事 Webフロントエンドの開発効率を高く保つための考え方 @adwdさんのこの記事に感銘を受けて、Twitterでちらほら感想をつぶやいたところLikeやRTが予想外に集まりました。それが下記のツイートです。 筆者がツイートしたもの 補足 筆者は、元記事で言及されている『「悪い方が良い」原則と僕の体験談』や『質とスピード（2020秋100分拡大版）』は確認済みであり、『 Clean Architecture 達人に学ぶソフトウェアの構造と設計
Ubie(ユビー)株式会社でソフトウェアエンジニアをしている八木(@sys1yagi)です。Ubieに入社してすでに1年8ヶ月くらい経ってますが(2019年4月入社)、入社エントリを書いていなかったので書きます。 【特にこんな人に読んでほしい】 ・Ubieに興味があるけど、技術スタック全然違うしな〜って思ってる人 ・キャリアとか転職とか皆どういう観点で考えてるんだろと気になる人これまでのキャリアソフトウェアエンジニアになって2021年でちょうど15年になります。Ubieに入社する2019年までは10年間ほどAndroidアプリケーションエンジニアをしていました。クックパッドのAndroid版をスクラッチしたり、新規事業のAndroid部分を担当したり（当時は一つのクックパッドアプリケーション内で複数事業の機能が入ってました）、新規事業がMBOして独立する際に技術部長を兼任しつつAndroi
達人出版会
探検! Python Flask Robert Picard, 濱野 司(訳) BareMetalで遊ぶ Raspberry Pi 西永俊文 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 知る、読む、使う！ オープンソースライセンス 可知豊 きつねさんでもわかるLLVM 柏木餅子, 風薬 デザインディレクション・ブック 橋本 陽夫 現場のプロがやさしく書いたWebサイトの分析・改善の教科書【改訂3版 GA4対応】 小川 卓 解釈可能なAI Ajay Thampi(著), 松田晃一(翻訳) PowerPoint 目指せ達人 基本&活用術 Office 2021 & Microsoft 365対応 PowerPoint基本＆活用術編集部 ランサムウェア対策 実践ガイド 田中啓介, 山重徹 TODによるサステナ
こんにちは。宿泊事業本部の宇都宮です。この記事では、GoのDIライブラリgoogle/wireの使い方を紹介します。 この記事は一休.com Advent Calendar 2019の9日目の記事です。 DIとは GoのDIライブラリ wireの使い方 Providerのエラーハンドリング Injectorのカスタマイズ Provider Set インタフェースのバインド 構造体のフィールドを参照する 細かな注意点 値とポインタの違いに注意 go runするときはwire_gen.goも一緒に おわりに DIとは DI(Dependency Injection, 依存性の注入)とは、あるオブジェクトが依存しているオブジェクトを自ら用意するのではなく、外部から渡してもらう（外部から注入する）というデザインパターンです。 例として、以下のように、監督の名前を渡すとその監督の映画を全てリストにし
Don't Use Frameworks :: Victor's Blog — Ramblings of a Software Professional
Stop using frameworks for everything. Just stop. You don’t need a framework to write good code and deliver products. Don’t get me wrong, frameworks are useful, but they are all-consuming and hide the application. So if you shouldn’t depend on frameworks what should you do instead? Clean architecture. More specifically, there are some patterns you can follow to better architect your application and
既存のシステム設計手法ではつらいので、数理的システム設計という手法をつくった #agileto2019 - うさぎ組
現代のソフトウェアシステムにおけるシステムアーキテクチャ設計手法や、それらをとりまく各種手法は素晴しい。だけど、わたしはまだまだもっと理想にちかづきたい。 そんな思いから課題をみつめて、自分なりに設計手法をつくってみました。 いまはこれを数理的システム設計とよんでいます。まだαバージョンくらいです。 いままでも、これについては筑波で2度勉強会をしており、今回はAgile Tour Osaka 2019で講演してきました。 アジャイル システム設計 Meetup - connpass システム設計ハンズオン勉強会 -リジェクトすえなみチャンス暑気払い- - connpass Agile Tour Osaka 2019 × miniPLoP 2019年11月9日（大阪府） - こくちーずプロ で、今回はたぶんはじめてスライドを公開しました。 スライドにある通りですが、基本的には僕の経験のみの話
Mirrativのバックエンド開発におけるMySQLとの向き合い方 - Mirrativ Tech Blog
こんにちは、バックエンドエンジニアのmakinoです。先日、LINE LIVEさんとの共催イベントにて「Mirrativを支えるバックエンド開発 ~MySQLとの向き合い方~」というテーマでLTをしました。 connpass.com speakerdeck.com 今回はLTの内容から一部抜粋して、Mirrativのバックエンド開発において遭遇したMySQLに関する問題と、その対策について紹介します。 問題 その1 データ量/QPSの増加に伴って、非効率なクエリが顕在化した サービス初期の段階ではデータ量が少なかったり、ユーザーのアクティビティが少ないために問題がなかったクエリも、サービスの成長に伴ってデータ量・QPSが増加したことによって、MySQLに負荷をかけてしまうことがありました。 具体例を以下にいくつか示します。 数千件レコードのfilesort 適切なindexが利用できればM
他の方の記事ですが、読んでいておもしろかったです。記事に出ている本はClean ArchitectureとTDD、LeanとDevOpsの科学くらいしか読んだことなかったです。 また自分も書くことで、他の方も記事を書くようになり、ついでに他の方の記事を読んでみるなどしたいなと思ったので書いてみます。 私はソフトウェアエンジニアとしてのキャリアはまだ7年くらい[1]なので短い方ですが、約7年間の中で読んで印象に残ったものを紹介します。 計算機プログラムの構造と解釈 Scala関数型デザイン&プログラミング Effective Java Programming Rust 実践ドメイン駆動設計 なお、この記事ならびに本のリストは誰かの役に立つことは想定しておらず、単に自分が読んで影響を受けているなあと感じる本をまとめています。つまり自己満足です。 加えてこの手の記事を書く際には、一応筆者のプロフ
概要 本記事は、スクラムを管理するアプリケーションをクリーンアーキテクチャの考え方で実装し、WebからもCLIからも動かせるようにしたという実践を紹介するものです。学習のための個人開発で作成したサンプルアプリケーションの設計と実装を適宜紹介することで、クリーンアーキテクチャに対する理解を深めることが目的です。 モチベーション なぜ現代の開発現場で定着しているクリーンアーキテクチャのアプリを手元で実装してみようと思ったかというと、私自身Webエンジニアとして働く中で、クリーンアーキテクチャの実践例は入出力をWebに限定したものばかりだったからです。 しかし、「詳細に依存せず抽象に依存すること」と唱えるクリーンアーキテクチャにとって、Webはただの詳細です。そこで、入力元、出力先を問わないアプリケーションはどのような書き味になるのか、自分で確かめてみたくなりました。 例えば、「ドメイン層は独立
スティーブ・マコネル（Steve McConnell）の著書『More Effective Agile』の第6章で、「ベルビンのチームロール理論」なるものが紹介されている。そこに、「Plant」や「Shaper」「Resource Investigator」など、聞き慣れない9つのロール名が並ぶ。チーム内でこれらのロールのバランスが取れていることと、チームのパフォーマンスの間には、高い相関があるそうだ。 そう言われると興味を持つ。ベルビンチームロールとはどのようなものだろうか。しかし残念なことに、同書からはほとんど情報を得られない。書かれているのは、先の9つのロールそれぞれに関する短い説明文と、次の引用にある記述ぐらいだ。 この理論では、チームにおいて人々がどのように行動するか、人々がどれくらい協力して作業を行うと考えられるか、そして各役割の候補者をどのように選択するかを評価する。 202
こんにちは。ティアフォーでWebサービス開発を担当している池谷です。 世の中はコロナで自粛モードが続いていますが、ティアフォーではリモートワークを活用し日々の業務に柔軟に取り組んでいます。 さて、私の所属するWebチームでは、オープンソースの自動運転OS「Autoware」を利用した多種多様なサービスを開発しています。その中でも代表的なサービスに「FMS」という運行管理サービスがあります。今回は、当サービスを開発してきた振り返りとして、主にドメイン駆動設計によるアーキテクチャの最適化に纏わるトピックについてお話したいと思います。 What's FMS? ティアフォーのFMSの注目機能 オンデマンド配車モデル 巡回走行モデル ベストプラクティスを求めて FMS開発における試行錯誤 浮上していた課題 開発手法のアプローチ ドメイン駆動設計 モデリングの実践 設計・実装面のアプローチ クリーンア
はじめに CastingONEでバックエンドエンジニアをやっている清水です。 この記事ではクリーンアーキテクチャについて学んだけど具体的にどのように実装すれば良いのかという悩みがあったので実装例をまとめてみた記事になります。 クリーンアーキテクチャで実装されたサンプル実装のうちGitHubのスター数が多いリポジトリをピックアップして、設計内容を紹介していきます。 具体的にどこにどんな実装をするべきなのかも含めて紹介していきます。 処理を一部省略して紹介するため実際の処理内容を確認したい場合はGitHubでご確認お願いします。 クリーンアーキテクチャとは クリーンアーキテクチャは、ソフトウェア設計の原則を適用して、依存性の方向性を逆転させ、ビジネスロジックから詳細（フレームワークやデータベース）を分離するアーキテクチャパターンです。これにより、テストしやすく、メンテナンス性が高く、柔軟性のあ
Clean Architecture: クライアントアプリの「中心」とは何か / 20200121 the center of the client #ios_ca
iOS Clean Architecture勉強会 sponsored by Sansan - connpass https://connpass.com/event/158269/ の発表資料です。 ## 参考資料 Clean Architecture 達人に学ぶソフトウェアの構造と設…
FlutterとFirebaseで開発した 英語の瞬間翻訳トレーニングアプリ Lala の技術 - Qiita
どうも、shoheiです。 株式会社Neverの代表です。 今回はFlutterとFirebaseで開発した英語の瞬間翻訳トレーニングアプリ Lala の技術を紹介します。 アプリはこちらからダウンロードできます（無料でご利用できます）。 ・iOS https://apps.apple.com/jp/app/id1493691416 ・Android https://play.google.com/store/apps/details?id=com.gmail.hukusuke1007.lala 目次 概要 開発期間 設計 主な機能 UI/UXデザイン ユーザーレビュー マーケティング その他 終わりに 概要 まずはLalaの概要を紹介します。アプリストアの情報をそのまま掲載します。 Lalaは英語の会話力向上を目的とした瞬間翻訳トレーニングアプリです。 次々と出題される文章を瞬間的に翻訳
PHP中級者がソフトウェア開発の理解を深めるためのオススメ書籍 約30冊（2020年版） — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
去年末（2019/12）にオススメ書籍をまとめてみたことがあったので、それを少し更新して公開します。 上にある書籍がよりオススメというわけではないです。 対象者は「PHP中級者」です。中級者が何かは難しいですが、初心者、初級者では決してないとは言えます。 改めて一覧にしてみると、かなり偏っているかも知れません（笑 こういうのはコンテキストというのがあるため、それが合わないと「お前は何を薦めているのだ？」となるでしょうね。 キーワードは、「モデリング」「オブジェクト指向プログラミング」「TDD」「デザインパターン」「DDD」「チーム開発」「アジャイルソフトウェア開発」「スクラム」でしょうか。 PHP中級者のイメージ たぶん、PHP中級者であれば、PHPに関することはPHPマニュアルなどを調べて解決できるでしょう。PHPのオープンソースプロジェクトに貢献しており、自分でプロジェクトを持っている
エンジニア組織のキャリア戦略とスタンスとして大事にすべきこと
こんにちは、株式会社エウレカでCTOをしている kaneshin です。 この記事は CTOA Advent Calendar 2020 の21日目の記事です。エンジニア組織におけるキャリア設計について、今までの私の経験を踏まえて考察してきたスキルの礎の部分について、いろいろな方にお話しする機会が増えたこともあり、今年の締め括りとしてエンジニア組織のキャリア戦略について一本書こうと思い、本記事を書いています。 はじめに株式会社エウレカは、恋活・婚活マッチングアプリ「Pairs」の運用とオンライン結婚相談所「Pairsエンゲージ」の展開をしています。私は2012年にエンジニアとして入社し、当時ローンチしたばかりのPairsチームへの配属となりました。（Pairsは以下「ペアーズ」と表記します） 入社当時は出会い系と同じ括りとして認識されていたペアーズですが、今ではこのようなクリエイティブを世
最初に: clean architecture は誤解されている 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』(以下『Clean Architecture』)を読んだことがありますか?例の同心円の図しか知らないという人も多いでしょう。 画像出典: Robert C. Martin 「The Clean Architecture」 さて、ここでクイズです。「Clean architecture とは、 controllers や use cases、entities というクラスを作って繋げるアーキテクチャのことだ、○か×か」。どっちでしょうか? → → → 正解は×です。 あの同心円は、あくまで clean architecture の一例として『Clean Acrhitecture』で紹介されたものです。 そう、clean architecture とはア
はじめに 「理解容易性」は「保守性」の観点の1つとして重視され、多くの原則や技法が紹介されているが、断片的かつ多様であり、全体像を理解することは難しい。 抽象度は高いが、体系的に観点を整理する事で、その理解の助けとなれば幸いである。 定義 「理解容易性」を簡単に言えば、「理解のしやすさ」であるが、その意味から掘り下げると、「思考する量」と言い換えることができる。 本記事では理解容易性を「思考量の少なさ」と定義し、7つの観点に整理した。 先に要約およびチェックリストを記載し、概略を記載した。 後に詳細で理解のため、各観点毎の説明と個別の原則や技法へのリンクを記載した。 要約 7つの観点の要約を先に示す。 （変数や関数の）名称は分かりやすくする （変数や関数の）役割は１つにする （変数や関数の）参照は狭くする （変数や関数の）状態は変えられなくする （関数やクラスの）面積は小さくする （関数や
TL;DR ADOP はヘキサゴナルアーキテクチャの実装パターンとして考えられます。 パターンという名前はそれに由来します。 あえて名付けた理由はこぼれ話をご確認いただけると幸いです。 ADOP の概要 ADOP (Application Domain Others Pattern) は中長期的に運用可能なコードへ誘導するアプリケーションアーキテクチャパターンです。 ADOP は次の特徴があります。 最小限のルールである 指針が明確である 特定の技術スタックに縛られない テスタビリティが確保される これらの特徴は、コードを自然と中長期的に運用可能なコードへ導きます。 まず、簡単にそれぞれがどういった意味を成すのかを確認してきましょう。 最小限のルールである どれほど完璧な作戦であっても、その実行が不可能であれば何の意味もありません。 プログラミングにおいてもそれは同じことで、制約を守るため
この記事は個人ブログの内容がソースです。 kami-programming.com そもそもなぜクリーンアーキテクチャーを考察するのか DRY原則やSOLID原則などが浸透している昨今ですが、実際の開発現場のソースコードを読み込んでみると必ずしもこれらの原則に則していない場合は多いのではないでしょうか。 そして、そういった開発環境でいざコーディングをしていくと、以下のような問題に直面するのではないでしょうか。 あるバグの修正をしたのだが、同じロジックが他の場所でも書かれていたようで重複箇所のバグは依然としてバグったままだった。 あるクラスを変更したが、依存性の方向性や範囲が把握しきれておらず、変更の影響で新たなバグを生んでしまった。 ビジネスロジックの変更を迫られたが、同じロジックが重複しすぎており修正範囲を特定するだけで一苦労。 想定外の値の入力があり、バグが発生してしまった。 これらは
リファクタリングに関する何か - 日々常々
リファクタリングの話をするとき、焦点が合ってないなーと感じることがたまにあるのでざっくり描いてみた。 自分のために描いたものなので、なんか違うなーって思ったらご自身で描いてみるといいと思います。レッツモデリング。 破線は依存、実線は変換。長方形は名前などで明確に識別可能なもの、角丸は様々なものを包含する活動。雲は思いです。 描いた時の経緯と言うか 該当ツイート: リファクタリングって常時やるものなんですよね。もちろん「よーしやるぞー」って感じで行うものもあるんですけど、それは深呼吸的な。 とは言え。やったことがない、やってはいけない文化（動いているコードに触ってはいけない）に染められてしまっている、そのような方に「無意識にやれ！」と言っても、何の意味もないので言いません。むしろ害悪ですらある。 該当ツイート: 無意識にやるようになって、ようやく「リファクタリング」がカタログ化される前の「偉
2022年版実践WPF業務アプリケーションのアーキテクチャ【設計編／後編】 ～ドメイン駆動設計＆Clean Architectureとともに
今回はいよいよ最終回となります。前回は非機能要件についてアーキテクチャを設計してきました。今回は代表的なユースケースを選定して、アーキテクチャの詳細な設計を蒸留していきます。また、開発者ビューについても設計を行います。利用者側の要件から出てきにくい、開発上に必要となる設計、テスト設計などを実施します。 ソースコード 実際に動作するソースコードは、GitHub上に公開しているので、ぜひご覧ください。ビルドや実行方法については、リンク先のREADME.mdをご覧ください。また、実際に動作させるためには次の2つのライセンスが必要です。 ComponentOne for WPF SPREAD for WPF 4.0J これらは試用ライセンスを発行することができます。 本稿だけで読み進められるように記載していますが、すべてのコードを詳細に解説しているわけではありません。本稿を読んだ後、あらためて動作
2019年ふりかえり - しゅみは人間の分析です
同人誌を生産する生活 同人誌制作が生活の中心だった。妻が同人活動を始め、それに振り回された一年といえる。妻はもともと絵を描く人だったが、ある日突然漫画も描くようになった。配偶者とはいえ、ひとの趣味なので始めは放置していた。だが、どうも雲行きが怪しい。スケジュールが破綻していたのだ。新刊が落ちるかもしれない、そんな状況で2019年を迎えた。年末年始の休暇をすべて費やし、私はスケジュール管理とアシスタントをすることになった。妻は1日に4ページの作画をこなし、私がベタとトーンを塗る。正月も休むことなく作業をし、締切前日には当然のように徹夜をした。 同人誌を作るのは文化祭の準備と似ている。あらゆる手段を使って完成させ、イベントで頒布しないといけない。本を用意できたら対面販売の喜びが得られる。インターネットで得られるただの数字とは違って、目の前の人が本を買ってくれるのだ。狭いスペースに何時間もいるの
Unityを利用した大規模なゲーム開発にクリーンアーキテクチャを採用した話 - WonderPlanet Developers’ Blog
こんにちは、タノシムスタジオテックリードの吉谷です。タノシムスタジオでは2011年ごろからクライアントアプリケーションの開発にUnityを利用し始め、いろいろ試行錯誤をつづけた結果、現在ではクリーンアーキテクチャの考え方を取り入れています。 今回は、Unityを利用したゲーム開発にクリーンアーキテクチャを適用した例として、導入理由、具体的な構成、実際に感じたメリット、デメリットなどを紹介したいと思います。 クリーンアーキテクチャとは クリーンアーキテクチャはRobert C. Martin氏が自身のブログにて発表した、すべてのソフトウェアアーキテクチャが守るべき考え方やアプローチがまとめられた概念です。以下のような同心円状の図で説明されることが多いかと思います。 出典： The Clean Architecture クリーンアーキテクチャの説明自体は、検索していただければ優れた記事や書籍な
達人出版会
探検! Python Flask Robert Picard, 濱野 司(訳) BareMetalで遊ぶ Raspberry Pi 西永俊文 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 知る、読む、使う！ オープンソースライセンス 可知豊 きつねさんでもわかるLLVM 柏木餅子, 風薬 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 Tom Hombergs(著), 須田智之(訳) 詳解 AWS CloudFormation 潮村 哲 その決定に根拠はありますか？ 確率思考でビジネスの成果を確実化するエビデンス・ベースド・マーケティング 小川 貴史, 山本 寛 プログラマーのためのVisual Studio Codeの教科書【改訂2版】 川崎 庸
本記事は ドメイン駆動設計#1 Advent Calendar 2019 19日目の記事です。 こんにちは、レガシーコードを 爆殺 リファクタリングするのが大好きなミノ駆動です。 今回はドメイン駆動設計導入上避けては通れない、大事な大事なお金の話を致します。 「ドメイン駆動設計を導入してみたいんです！」 部下「ドメイン駆動設計を導入してみたいんです！」 上司「それって何？なんのために導入するの？」 部下「…………」 はい、僕にもそんな時代がありました。 何のためにドメイン駆動設計を導入したいのか、簡潔に説明できますでしょうか。 「ドメイン駆動設計」のタイトルにあるように、本書は設計に関する書籍です。 ソフトウェア全体の設計手法や思想に関して言及している書籍です。 まずはソフトウェアの価値とは何か、設計とは何か、それぞれ何かを整理してみます。 ソフトウェアの価値 ソフトウェアが満たすべき要件
開発効率を追い求めた実装プラクティス集
この記事は MICIN Advent Calendar 2023 の24日目の記事です。 前回はSaneさんの「データ基盤チームで社内インターンをやってみて」でした。 はじめに abekohです。MICINでMiROHAの開発をしております。 本記事では、書籍等から得た設計・実装パターンの知識や、実際にプロダクト開発で試して得られた経験などから編み出した、開発効率向上のためのWeb API開発のプラクティスを紹介します。 筆者が関わっているMiROHAは治験の業務支援を取り扱うプロダクトです。MiROHAの開発における特性として、以下のようなものが挙げられます。 治験業務に関するドメインが特有で複雑 前例が少なく、MVPを追求中。プロダクトのアプローチが頻繁に変わる 外部品質は高い水準が求められる これらの特性を意識して開発を促進させるために日々試行錯誤しております。 複雑なドメインに対す
Why? Clean Architectureを通読してみたが、抽象論が多いのでやっぱり書いてみないとな、と思った次第。 いろいろな方のClean Architectureの記事があるものの、当方Typescripterなので馴染む言語で写経すると理解が深まるだろう。 Assumption フレームワーク・ライブラリ非依存。Clean Architecture の構造だけ再現するので、サーバフレームワークやORMなどは使用しない。 命名はClean Architectureに出てきたままを心がける。一部、原文でも表現がブレているのは都合よく拝借。 Clean Architecture Overview Clean Architectureといえばこの図。 最重要エンティティであるビジネスロジックを中心に、アプリケーションロジック、インターフェースアダプター、フレームワークやDBの順で依存方
いつScalaを使い、いつ使わないのか
前置き 先日Twitterでこのような興味深いツイートを拝見しました。 なるほどと思ったので、自分が技術選定/アーキテクチャ設計において「どのような時にScalaを選択し、どのような時に選択しないのか」をあらためて言語化してみることにしました。 ちなみにこの記事タイトルは Scala福岡 2019 で講演させて頂いたものと同じタイトルですが、当時の資料は説明が無いと誤解を招く部分も多く非公開にしているため、その焼き直しも含めてこの記事を書いています。 また、ここで記載している内容は2022年8月現在の事情を元にした考えになります。言語の機能やとりまく状況などは日々変わっていくものであり、前提が変われば結論が変わることも当然にあります。あくまで現時点での意見の一つとして参考程度にして頂ければ幸いです。 また、この記事では主に言語機構や周辺ライブラリ・エコシステムといった側面からの判断を中心と
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Clean Architecture の勘所は『鎖国』だ。 - Qiita
Goのテストに使える手作りモックパターン - Money Forward Developers Blog
Clean Architecture on Frontend
非エンジニアサイドに技術的負債や設計を説明するノウハウ - Qiita
Lambdaのテスト領域に関する技術共有会を開催しました | DevelopersIO
goquを駆使してgoでSQL構築も構造体マッピングもRDBテストもやる - エムスリーテックブログ
フロントエンドで長持ちするプロダクトを開発するための心構え
事業とプロダクトで転職先を選んだら一致する技術スタックがほぼ0個だった話｜sys1yagi
GoのDIライブラリgoogle/wireの使い方 - 一休.com Developers Blog
ソフトウェアエンジニアをしていて影響を受けた5冊（+α）
TypeScriptでクリーンアーキテクチャを実践する
9つのチームロールでチームワークを強化する / ベルビンチームロール - mtx2s’s blog
ドメイン駆動設計による運行管理システムのアーキテクチャの最適化 - TIER IV Tech Blog
Go言語によるクリーンアーキテクチャの実装例紹介
ウェブフロントに見る clean architecture の一例
理解しやすいコードの書き方～理解容易性の7つの観点～ - Qiita
ADOP (Application Domain Others Pattern)
Clean Architecture考察 - ROXX開発者ブログ
ドメイン駆動設計で貧乏を爆殺する - Qiita
Clean Architectureを読んだまま実装してみた（TypeScript, Go）