Lunash
ソフトウェアエンジニアのNashが技術、キャリア、雑記などについて書いている個人テックブログ。 #新着(132) 2023年の振り返りと2024年の抱負 キャリア 2024-01-13 #キャリア 社会人学生１年目｜働きながら放送大学で心理学を学ぶ 雑記 2023-12-04 #放送大学 ScyllaDB Universityでお勉強 技術 2023-07-03 #ScyllaDB RustのプロジェクトでMVCからClean Architectureにリアーキテクチャした話 技術 2023-06-22 #Rust Read More(132) #技術(54) GatsbyからAstroへブログをリプレイスした話 技術 2023-04-21 #Astro #Gatsby 書評｜「良いコード／悪いコードで学ぶ設計入門」 技術 2023-01-17 #書評 TypeScript｜ブロック文で変
2019/10/27 (Sun) に開催された .NET Conf Tokyo で発表した、Unity で Clean Architecture を適用してみた話です。
パラレルワーカー兼大学生になることになった · the world as code というエントリーで SRE の立場でやっていくということを書いて、実際働き始めて3か月近くが経過した。インフラ系の運用専門のエンジニアから SRE という立場に変わって実際のところ何が変わったのか、今後何をするべきなのかということを、ここで改めてまとめておきたい。 改めて SRE を定義する SRE の職種で転職活動をしていたとき、カジュアル面接で「SREとはなんだと思うか？」と聞かれたことがあった。そのときには「ソフトウェアエンジニアリングを用いてシステム運用を行うこと」と応えているが、今から考えると「半分正解」ぐらいの応えだったように思っている。 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチームposted with amazlet at 19.09.
2022年版実践WPF業務アプリケーションのアーキテクチャ【設計編／中編】 ～ドメイン駆動設計＆Clean Architectureとともに
前回記事では、初期のドメインビュー・ユースケースビューから、アーキテクチャを設計していくための土台となる初期の論理ビュー・実装ビュー・配置ビュー・データビュー・プロセスビューの設計を行い、全体の大まかな設計を行いました。その結果、個別の非機能要件やユースケースを個別に設計できる状態になりました。そこで今回は、ユースケースを設計する前に事前に設計しておいたほうが非機能要件について設計を進めます。具体的には認証・例外・ロギングのアーキテクチャです。これらはユースケースの設計に影響を与えたり、設計に応じた仮実装を進める上で、事前に決められていたほうが扱いやすい要素だからです。 ソースコード 実際に動作するソースコードは、GitHub上に公開しているので、ぜひご覧ください。ビルドや実行方法については、リンク先のREADME.mdをご覧ください。また、実際に動作させるためには次の2つのライセンスが必
No more LiveData in Your Repository: There are better options.
Three years ago at a Google I/O that every Android developer remembers, Google announced Android Architecture Components and we were all excited about it. ACC has definitely changed the way we build Android Applications. ViewModel and LiveData have both taken an important place in our day-to-day app design. LiveData is the main topic of this post. Don’t get me wrong LiveData is a very powerful and
C# Tokyo ユーザーコミュニティのイベント - C# Tokyo オンライン「世界一わかりやすいClean Architecture」他 で発表した内容です。 動画の原稿はこちらに公開しています。 https://www.nuits.jp/entry/easiest-clean-architecture-2019-09 またサンプルコードやPowerPointファイルはこちらに公開しています。 https://github.com/nuitsjp/Easiest-Clean-Architecture あわせて御覧ください。
爆速開発を目指して NewsDigest を Flutter にリプレイスします JX通信社 Engineering Manager の @jazzsasori です。 最近アークナイツというソシャゲに課金してしまいましたが妻には内緒にしています。 弊社は NewsDigest という無料ニュースアプリを運営しています。 NewsDigest は記者が業務で愛用するほど、その圧倒的スピードに強みがある速報アプリです。また、一般的なニュース分野での速報に加えて、報道はされにくいが個人にとって価値の高い情報も to B 向けのリスク情報SaaS である FASTALERT と連携して即時に伝える、社会派ニュースアプリです。 現在 (2021/11) 500万ダウンロードを突破しており、今後もさらにユーザーを伸ばそうとしています。 なぜリプレイスを行うのか サービスとしては 2015年 にストア
2020年度版おすすめ書籍 in マネフォ京都メンバー - Money Forward Developers Blog
TL;DR これはMoneyForward Kyoto Advent Calendar 2020の14日目になります。 担当は本年はこれが最後のアドベントカレンダーになる予定の luccafort です。 投稿記事5つはね…多すぎたよ。 開発メンバーが選ぶ、おすすめの技術書【2020年度】 - RAKUS Developers Blog | ラクス エンジニアブログが良さそうなので、マネフォ京都版を作りたくなり、やってみました！ ルール 以下の条件を満たしていれば技術書から一般書籍、あるいは漫画や雑誌でも何でもOKです！という緩い制約で募集しました。 2020年に読んだ/読んでいる/読もうとしている書籍 選んだ理由が書ける というわけで京都メンバーが普段どんな書籍や技術書に興味を持って読んでいるのか個人的に気になっていたので大変楽しみです！ みんなが欲しかった！簿記の教科書 著者名: 滝澤
テストしやすいGoコードのデザイン
テストしやすいGoコードのデザイン golang.tokyo #2 12 December 2016 Taichi Nakashima 言いたいこと 明示的であれ！ 2 whoami @deeeet / @tcnksm (GitHub) http://deeeet.com A PaaS Dev&Ops (Using go for CLI tool, API, Batch jobs) 3 OSS Tools gcli - The easy way to build Golang command-line application ghr - Create Github Release and upload artifacts in parallel Packages go-httpstat - Go package for tracing golang HTTP request latency
背景 Clean Architecture に則ってレイヤ間をプラガブルにするためにインタフェースを使っていくと、テストのために各インタフェースのモックが欲しくなります。 そのモックを生成する際にgolang/mockを使用するわけですが、毎回 $ mockgen -source user.go -destination mock_user.go とするのは手間です。また たまにしか使わないので書式、オプションを覚えていない モックの吐き出し先ルールがファイル、パッケージ、リポジトリによって異なり把握がしづらい など運用が辛くなりがちです。 かと言って「じゃあレイヤまるごと対象にしよう」とシェルスクリプトで for file in $(ls ${SOME_LAYER_DIR} | grep -v "_test.go"); do mockgen -source ${SOME_LAYER_DI
GopherCon 2019 会場入口*1 こんにちは。シニアエンジニアの濱口です。 以前に下記の記事で掲載したGopherCon 2019への参加しましたので、イベントの様子や体験をレポートします。 techdo.mediado.jp プラン 会場はアメリカ カリフォルニア州 サンディエゴの、マリオット マーキスというホテルです。 イベントの日程は 7月24日から27日までの4日間のため、23日に出国し、28日に帰国しました。イベント本番は25日から27日まで3日間ですが、今回は24日のプレカンファンレンスにも参加をしました。 24日: プレカンファレンス 25日: セッション1日目 + ウェルカムパーティ 26日: セッション2日目 27日: コミュニティーデー プレカンファレンスはイベント本番とは別料金であり、内容は丸一日かけたワークショップなどです。今回メディアドゥから参加した私と
ビジネスロジックとは何か？
業務システムの設計/開発/運用の文脈での、ビジネスロジックについて考察してみたいと思います。 ソフトウェア設計についての本やブログ記事などで、「ビジネスロジックは重要である」ということは、何度も何度も言われていて常識になっていて否定する人はほとんど居ないと思います。この点については文字通りの意味で納得するところなのですが、「ビジネスロジック」というのは、何なのでしょうか？ 実際のところ ビジネスロジックとは何か？と問われて思いうかべる事は人によって異なるかもしれません。 要件定義書に書かれていることがビジネスロジック？ 基本設計書に書かれていることがビジネスロジック？ ○○テーブルの××カラムと□□テーブルの△△カラムを同一トランザクションで更新することがビジネスロジック？ あるページの○○ボタンをクリックしたら、行を削除するということがビジネスロジック？ どうも捉え所が無い感じです。 W
On layered architecture ? Layering is not a novel concept. It’s been around in the industry for more than a couple of years (some of you reading this document are probably younger than layering) and it’s one of the first architectural styles created. In short, layering is nothing more than dividing the concerns of your application into different layers, like in a cake, where the upper layers can t
今年の初め頃から少しずつアーキテクチャやDDDの勉強を初め、プロジェクトの中で手探りで実践してきました。 そのまとめと振り返りを兼ねて、Go言語でDDDとクリーンアーキテクチャを意識した実装を行う場合の簡単な実装例を記載していきます。 GoはJava等と違い完全なOOPを実現するような言語ではないので、あまりガチガチに追求しすぎるよりも、 ある程度妥協しながらGoの良さを活かしつつ落とし所を見つけて行くのが良いのではないかと思います。 未だ試行錯誤しながら実装しているものですので、ご意見/ツッコミ大歓迎です。 Domain Object エンティティや値オブジェクトといったドメインオブジェクトはデータと振る舞いから成るもので、 Goでは構造体とそれが持つプロパティ値、関数で表現します。 type Users struct { id int firstName string familyNa
達人出版会
［令和6年度］基本情報技術者 超効率の教科書＋よく出る問題集 五十嵐 順子 徹底攻略 データベーススペシャリスト教科書 令和6年度 株式会社わくわくスタディワールド 瀬戸美月 著 徹底攻略AWS認定SysOpsアドミニストレーター - アソシエイト教科書＆問題集［SOA-C02］対応 鮒田 文平, 長澤 美波, 日暮 拓也, 奥井 務, 渡辺 樹, 山下 千紗, 伊藤 翼 世界標準MIT教科書 アルゴリズムイントロダクション 第4版 第2巻 高度な設計と解析の手法・高度なデータ構造・グラフアルゴリズム Thomas H. Cormen, Charles E. Leiserson, Ronald L. … 問題解決の教科書 CITA式問題解決ワークブック 市岡 和之 はじめてのType-C電子工作 じがへるつ スッキリわかるJava入門 実践編 第4版 中山 清喬(著), 株式会社フレアリ
The API database architecture - Stop writing HTTP-GET endpoints
The API database architecture - Stop writing HTTP-GET endpoints Table of contents Introduction Data retrieval via PostgREST, data modification in the existing backend Compatibility with REST, CQRS and GraphQL Strategies for adapting existing architectures Adapting a monolithic system with a single backend Adapting (domain-driven) microservices with one or more databases Benefits of the API databas
株式会社LegalForce
契約に関するペインをRubyで解決 東京都千代田区に本社を置く株式会社LegalForceは、自然言語処理を用いたクラウド型契約書レビュー支援ソフトウェア 「LegalForce」を提供している。契約書に潜むリスクを一瞬で洗い出し、自動で契約書に含まれるリスクに対してアラートを出すレビュー機能や、契約書を条文ごとに検索することのできる条文検索機能などを搭載し、法務業務の効率化を実現できるサービスだ。 このサービスはRubyを使って開発されていると聞き、同社CTOの時武氏、CROの舟木氏にお話を伺った。 法律事務所が隣にある環境 ビジネスをする上で避けて通れないのが契約書の締結だ。このチェック業務に多くの時間を費やしている会社も多いのではないだろうか。取引の実態に即しているかどうか、自社に不利なな条文が含まれていないかどうかなど、様々な視点で確認する必要があり非常に手間のかかる作業だ。 こう
Clean Architectureとは Clean Architecture(クリーンアーキテクチャ)とは，レイヤに内側と外側の関係性を持たせるアーキテクチャである． 「外側のレイヤは内側のレイヤだけに依存する」というルールを守ることによって，アプリケーションから技術を分離することが目的である． アプリケーションから技術を分離すると何が嬉しいのか ここでの「技術」とは，HTTPやcsv，MySQLなどのことを意味している． アプリケーションから技術を分離すると，技術を容易に変更できたり，テストコードを書くときに容易にモックできたりする． 例えば，出力をHTTPからcsvに変更したくなったときなどに容易に変更が可能である． 各レイヤの責務 Clean Architectureで提案されているレイヤ構造は以下の画像のようなものである． 内側から，Entitiesレイヤ，Use Casesレイ
If you are a master software engineer, you can stop reading. This post isn't for you. This post is for people who are like me, mediocre programmers who write messy code and create spaghetti architecture but are fascinated with the idea of building something clean, maintainable, and adaptable. Preface I don't usually buy computer books because they get outdated so quickly. Besides, I can find all t
テストケースを変えない工夫 | 品質向上ブログ
※本稿はソフトウェアテスト Advent Calendar 2020 24日目の記事です。 こんにちは、Magic Podの開発をしている脇坂です。好きなものは単体テストとリファクタリングとテニスです。 さて、今日はリグレッションテスト、機能テストの文脈で話をします。テストケースを変えない工夫というのは、継続的にテストケースを実行する上で必要不可欠なテクニックです。このテクニックは自動テストの文脈で語られることが多いですが、手動テストにおいても応用可能だったりします。 話すこと テストケースを変えるべきではない理由テストケースを変えずに済ませる工夫 話さないこと フレーキーテスト問題に対するシルバーブレッド非機能要件のテスト 目次 背景テストケースの変更単体テストの場合Web/Mobile E2Eテストの場合Webは詳細手動テストの場合Web/Mobile E2Eテスト自動化サービスの場合
Clojure x ClojureScript で深める Web 開発 (5) API 開発 トランザクション添え - Qiita
Git Repo ソースコードと原文が入ったレポジトリ https://github.com/MokkeMeguru/clj-web-dev-ja/tree/main/chap5 シリーズ Clojure x ClojureScript で深める Web 開発 (0) Clojure x ClojureScript で深める Web 開発 (1) Duct x Clean Architecture Clojure x ClojureScript で深める Web 開発 (2) 環境の構築 Clojure x ClojureScript で深める Web 開発 (3) API 作成入門 Clojure x ClojureScript で深める Web 開発 (4) Auth Clojure x ClojureScript で深める Web 開発 (5) API 開発 トランザクション添え C
サーバーサイド未経験の大学生が4日でGolang×CleanArchitectureのAPIを構築した話 - Qiita
【追記：2019/9/17】 記事で誤りがあった部分を修正いたしました。 またサンプルも正しいものに修正しておりますので、是非ご確認ください。 【追記:2019/9/10】 コメントでもご指摘を頂いておりますが、一部誤った内容が含まれております。 すぐに修正に取り掛かりますが、内容の修正まで今しばらくお待ち頂けますようお願いいたします。🙇♂️ また、今回多くの方に誤った内容をお伝えしてしまったこと、深くお詫び致します。 （多くのいいねを頂いており、ストックに登録して頂いている方もいらっしゃると思いますので、非公開にせず修正又は内容の削除で対応致します。） 先日インターンでソシャゲ用のAPIを作った時に、サーバーサイド未経験ながらGolang＆クリーンアーキテクチャ（的な）のAPIを構築しました。 特にインターンで用意されていた内容というわけではなく、個人の課題としてクリーンアーキテクチ
Webフロントエンドでも Clean Architecture に関する考察や実際のサービスへの導入の事例をよく見かけるようになりました。 n番煎じですが Clean Architecture をWebフロントエンドのアプリケーションに導入する際の考察をコードを書きつつしてみました。 サンプルコード はこちらにあります。 また、今回のコードを書くにあたり、 @ttiger55 さん、@pirosikick さんのエントリーやコードを参考にしました。ありがとうございます :) Pros/Cons コードを書いてみた上での結論を先に述べておきます。 Pros/Cons で言えば Pros の利点が多く感じられますが、結局のところ「ビジネス要件」がある程度固まっているか否かというソフトウェア側でコントロールしにくい箇所がボトルネックとなっているのため、ここをどう捉えるかは個人によって差が出そうか
Abstraction Actor Model Architecture AI Algorithms Anti Patterns Architectural Design Principles Architecture Decision Records (ADR) Azure Cloud Back Pressure Caching Clean Architecture Clean Code Cloud Best Practices Cloud Design Patterns Cloud Native Code Review Concurrency CQRS Data Driven Design Design Best Practices Design Patterns DevOps Distributed Locking Distributed Transactions & Saga Do
11+ Best Nextjs Templates & Themes in 2024 | Creative Designs Guru
React SaaS Starter Kit with Next.js and TypeScriptReact Templates for building SaaS applications with Next.js, TypeScript and Tailwind CSS. A SaaS Starter Kit with a clean architecture and a multi-tenant architecture.
My Favorite System Design and Software Architecture Books for Experienced Developers
My Favorite System Design and Software Architecture Books for Experienced Developers Disclosure: This post includes affiliate links; I may receive compensation if you purchase products or services from the different links provided in this article. Hello guys, System design and Software architecture are two important topics for coding interviews and also two important skill for Software developers.
クリーンアーキテクチャですが、hanami/hanami: The web, with simplicity. と出会ってから5周回くらいして、ようやく腹落ちしつつあるのでまとめてみます。 フレームワークを利用しつつ理解するのは難しい フレームワークを利用した場合、例の図のUsecaseの外堀をグルッと埋める形になります。MVCならController、View、Modelです。Hanamiの場合はRepositoryが来ます。個人的にはこの内側から3層目が全て一体化していると、どうしてもそれらが中心であるように感じてしまうんですよね。 そこでアプリケーションのそれぞれの責務を別のライブラリを利用して実装することを試してみました。 これです。 cc-kawakami/clean-architecture-minimal-app: A minimal Clean Architecture a
Clean Architectures in Python - Chapter 1 - A day in the life of a clean system
Must be my lucky day. Terminator 2, 1991In this chapter I will introduce the reader to a (very simple) system designed with a clean architecture. The purpose of this introductory chapter is to familiarise with main concepts like separation of concerns and inversion of control, which are paramount in system design. While I describe how data flows in the system, I will purposefully omit details, so
はじめに この記事ではVertical Slice Architectureと呼ばれるアーキテクチャパターンについて解説します。Vertical Slice Architectureはこの2,3年の間にいくつかのブログポスト[1][2][3][4]で言及されているアーキテクチャです。Clean Architectureに対する反省から生まれたアーキテクチャであり、機能（feature）に沿ってモジュール分割を行う点が特徴です。 まず、Clean Architectureについて説明してからVertical Slice Architectureについて説明します。最後に私のコメントとして、Vertical Slice Architectureに対する評価、Clean Architectureに対する評価、それから日本でVertical Slice Architectureが受容され得るかどう
この記事は GraphQL Advent Calendar 2020 14 日目の記事です。 前回の記事は @joe-re さんの 「ライブラリの実装からCursor-based paginationにおけるcursorのフォーマットのベストプラクティスを探る」 でした。 前置き GraphQLは2010年代後半に出てきた技術の中でも個人的に特に強力なアプリケーション実装パターンの一つだと思っているのですが、シンプルな実装なのに利用用途が豊富にあることと利用する立場が違うと全く印象を抱く事から全体像を掴みづらく、本来持つべきポテンシャルに対してまだ認知が広がっておらず利用されていないように感じます。 今回はサーバーサイドからの視点を中心にGraphQLを構築する要素を分解して解説するのとともに、それを利用した際にWebアプリケーション開発やそれに関わるエンジニアに起きうる変化について書いて
導入 お疲れ様です、ベイジでエンジニアをやっている天野です。 ベイジではWebアプリのビジュアルデザインやフロントエンド実装の案件が増えてきており、エンジニアは日夜設計に頭を悩ませています。今回は、その中で個人的に良いと感じたフロントエンドの設計について共有します。 注意点として、ベイジではモックアップ実装の案件が多く、サーバーサイドとの通信の部分に関しては実装しないことが多いです。よって本記事では、UIなどWebアプリにおけるViewの話が中心となります。 ディレクトリ構成 最初にディレクトリ構成を示すことで、本設計の概要をつかんでもらいます。 src // ルートディレクトリ ├─infrastructure // インフラ層。バックとの通信やデータ管理を担う │ ├─domain // APIのインターフェースの定義など │ ├─interface // データの通信処理 │ └─r
自分がフロントエンドのアーキテクチャを考える時に、特に意識していることについてまとめてみました。 改善するべき点が多いと思っていますが、自分の考えを整理する意味で書き残したいと思います。 ここで言う「アーキテクチャ」とは？ この記事では、アーキテクチャについて主にコード間の依存関係の観点で考えています。 「なぜ依存関係なのか」については、次の意識しているポイントで触れていきます。 意識しているポイント 捨てやすくする 書いたコードを捨てやすいようなアーキテクチャを目指したいと思っています。 なぜなら、最初から良い設計はできないからです。（まれにできる人もいますが、少なくとも自分はできないです） 開発を重ねて理解が深まることで、より良い設計が見つかります。 良い設計が見つかった時に、既存のコードの修正・削除が必要になりますが、それができないと実現（実装）できないことになってしまいます。 コー
Echo（Golang web framework）のディレクトリ構成の参考情報 - OSS「echo-sample」のコードリーディング - ryotaku's Tech Blog
TL;DR echo-sampleは、こんな構成だった TL;DR きっかけ echo-sampleの概要 ディレクトリ構成 個々の構成毎の役割 main.go 役割 詳細 route 役割 詳細 middleware 役割 詳細 handler 役割 詳細 db 役割 詳細 conf 役割 詳細 api 役割 詳細 model 役割 詳細 /db/ddl.sql 役割 詳細 参考リンク きっかけ 業務で、GolangとそのWebフレームワークのEchoで、APIサーバーを作る機会があったのですが、初めて触るのでディレクトリ構成で悩みました。 必要なのは、Clean Architectureなどでガッツリ分離する必要も無いくらいのシンプルな機能のみなので、OSSで程よい構成のお手本を探しました。 いくつかEchoを利用したリポジトリがある中で、echo-sampleが簡潔な構成で参考になり
やまかわアドベントカレンダー Advent Calendar 2023 - Adventar 1日目の記事だよ！ このアドベントカレンダーはノンジャンルだけど、買ってよかったものみたいなお題があるんで、じゃあ今年読んでおもしろかった本とか紹介してみようと思いました。 技術書も実用書もお話も漫画もとりまぜていってみましょう。 六人の嘘つきな大学生 www.kadokawa.co.jp 殺人事件じゃないミステリー。 1ページごとにどんでん返しがあるみたいなジェットコースター展開なので飽きることなく一気に読めちゃいます。楽しいよ。 読者への解けるかなという挑戦という正統派ミステリーとしてよくできているかっていうと、目指しているのはそっちではないかもしれない。 でもページめくるごとに急展開でもってかれるのは気持ちいいし、あと何より大事なこととして読後感とても良いです。だからおすすめ。 話題のミステ
プログラミングにおけるテスト｜erukiti
僕はQiitaとNoteそれぞれでブログを書いていて、それぞれコードがある技術的なものを前者、それ以外をNoteで書くという書き方をしてます。まぁもっと言ってしまうと、ポエミーなヤツはNoteに書くって感じです。 最近よく考えるテーマとしては、テスト（ここでは自動テストを指します）というものがあります。今日の記事はそんなテストに関するポエムというか、筆者の頭の整理のために書いたものです。 どうにもTDDは誤解を受けやすいTDD（テスト駆動開発）には色々な要素が巻き込まれしまっている分、誤解されやすいものです。 一番誤解されやすいのはテストファーストとの混同です。 最初に落ちるテストを書いて、それに受かるコードを書いて、コードをリファクタリングする、という工程はものすごくキャッチーで知名度が高いものですが、TDDにおいて必須要件ではありません。 そもそも、TDDにおいて、自信があるならテスト
この記事は @yushi_koga さんの Qiita - オブジェクト指向プログラミングとドメイン駆動設計を学ぶのに適切な書籍とおすすめの読む順番 の後追い記事です。 DDD を学ぶ上で手助けとなるものを書籍に限らず紹介します。 自分如きがこんなキュレーション記事を書いて良いのか？という気持ちに怯えつつ書きます。 上記の記事で紹介された書籍以外で OOP や DDD に言及しているものを紹介します。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 DDD と共に語られることの多いクリーンアーキテクチャの本。 OOP や設計原則、凝集性などについても学べる。 .NET のエンタープライズアプリケーションアーキテクチャ 設計原則、ドメインモデリング、CQRS などについて学べる。 （以前は Kindle 版があったのですが今は何故か無くなってました） 「実践ドメイン
Clean architecture of Flutter application. Part 1 - Theory
Clean architecture of Flutter application. Part 1 - Theory Flutter is a rapidly developing cross-platform framework. It is really perspective technology, the state of the art of cross-platform tech. So, let's figure out how to build a good supportable architecture of Flutter application. This is the first part of a two-part article dedicated to flutter clean architecture. Today I would like to tel
Clean Architecture (CA) is the system architecture guideline proposed by Robert C. Martin (Uncle Bob) derived from many architectural guidelines like Hexagonal Architecture, and Onion Architecture, among others. Eric Evans introduced the concept of Domain-Driven Design (DDD). He wrote about it in his book Domain-driven Design in 2004 (aka “The Big Blue Book”). Domain-Driven Design is an approach t
【連載 第6回】新規プロダクト＆新造チーム＆フルリモート：そのときEMに何ができるか？ - freee Developers Hub
TL; DR 新規プロダクトを新造チームで開発するとき、私のとったEMとしての行動は、ブランコを漕ぐ子どもの背に手を添える母親と同じものでした。 はじめに freeeの金融開発チームでエンジニアリングマネージャーをしている横田と申します。このfreeeカード Unlimited連載企画では、これまでWebアプリ開発エンジニアの視点からの記事を5本続けてお届けしました。 【第1回】freeeカード Unlimited の開発の道のり 【第2回】freeeカード Unlimited での非同期通信の設計と実装 【第3回】EMから再度エンジニアとしてプロダクト開発に挑戦して学んだこと 【第4回】freeeカード Unlimited でのClean Architecture実践 【第5回】新卒1年目からの新規プロダクト開発 ここで一息ついて、開発チームを下支えする私の立場からのエントリーを投稿させ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Clean Architecture for Unity
SRE になって3か月目に考える、 SRE とは何か、如何に実践すべきか - chroju.dev
世界一わかりやすいClean Architecture #csharptokyo
爆速開発を目指して NewsDigest を Flutter にリプレイスします - JX通信社エンジニアブログ
go generateでモックを生成する - Carpe Diem
GopherCon 2019に行ってきました - Tech Do | メディアドゥの技術ブログ
Clean Architecture For React
GoによるDDD / Clean Architecture 実装 - Qiita
React + Recoil で Clean Architectureの構成を考えてみた
Go言語とClean ArchitectureでAPIサーバを構築する - Qiita
Clean architecture for the rest of us | Pusher tutorials
Webフロントエンド Clean Architecture 考 - Qiita
Awesome Software Architecture
小さなライブラリ群によるアプリでクリーンアーキテクチャをいい感じに理解する - Qiita
Vertical Slice Architectureについて
GraphQLはサーバーサイド実装のベストプラクティスとなるか - Qiita
俺流フロントエンドのディレクトリ構成と設計の考え方 | techlab / baigie
フロントエンドのアーキテクチャを考える時に意識していること
2023年こんな本がおもしろかった - またお前かよ！
ドメイン駆動設計を学びたい人にお勧めする書籍 + Twitter アカウント + α - Qiita
DDD and Clean Architecture — part 1