【ZOZOTOWNマイクロサービス化】API Gatewayの可用性を高めるノウハウを惜しみなく大公開 - ZOZO TECH BLOG
はじめに こんにちは。ECプラットフォーム部のAPI基盤チームに所属している籏野 @gold_kou と申します。普段は、GoでAPI GatewayやID基盤（認証マイクロサービス）の開発をしています。 先日、【ZOZOTOWNマイクロサービス化】API Gatewayを自社開発したノウハウ大公開！ を公開したところ、多くの方からご好評いただきました。ありがとうございます。まだ読まれていない方はぜひご覧ください。 techblog.zozo.com 今回はその記事の続きです。API Gatewayは単にリバースプロキシの役割を担うだけでなく、ZOZOTOWN全体の可用性を高める仕組みを用意しています。本記事では、それらの中でカナリアリリース機能・リトライ機能・タイムアウト機能に関して実装レベルの紹介をします。 マイクロサービスに興味ある方や、API Gatewayを自社開発する方の参考に
基礎から応用までじっくり学ぶECS Fargateを利用したコンテナ環境構築 #Fargate | DevelopersIO
こんにちはコカコーラ大好き、カジです。 7/3に行われたDevelopers.IO 2020 Connect で、「基礎から応用までじっくり学ぶECS Fargateを利用したコンテナ環境構築」というタイトルで、お話しさせていただきました。 ライブに来ていただいたみなさま、ありがとうございました！ お客様や自社の開発部門から、急に「次のシステムはコンテナ使いたい」と言われ、コンテナ実行環境を構築しなければならない状況に直面し、慣れない部分が多いと思います。 AWSにはコンテナ向けのサービスは複数あり、少人数でも運用しやすいのがECS Fargateです。そんなECS Fargateを中心に、実用的なコンテナ実行環境をどのように構築すれば良いのかについて解説しました。 目次 なぜコンテナ? なぜECS Fargate? AWSコンテナ関連サービス コントロールプレーンのざっくり比較 データプ
Zennのバックエンドを Google App Engine から Cloud Run へ移行しました（無停止！YES！）
Zennは、Next.js + Ruby on Rails（APIモード）を Google Cloud の App Engine へデプロイして稼働していました。最近、Rails の実行環境を App Engine Flexible から Cloud Run へ移行したので、その記録を残します。 ロードバランサーのバックエンドサービスを付け替えることで実現 最初に、どうやって移行したかです。Zennのバックエンドはもともとロードバランサーで構成されていました。以下の図のように、ロードバランサーの Backend Service より背後を切り替えることにより実現しています。Cloud Run とそこにアクセスするための Serverless NEG はあらかじめ稼働させておくことで、ダウンタイムなしで切り替えられました。 参考：負荷分散 | Google Cloud https://clo
久々に記事を書いてみました。スタートアップの経営者やCTOというポジションを今担っている人、これから目指す人向けに私見をまとめた乱文です。直近はCTOというよりも、もはやポジション名もわからないなにかになってしまい、人事や総務、マーケティング、各事業の経営管理など職責を広げすぎてしまいましたが、今回は自分にとってのCTOの職責として重要なものとは何かを考えてみました。 要点事業をスケールさせるためには、まず組織とプロダクトの設計が相互に影響し合うことを理解する。その上で事業構造の理解から、より素早く改善すべきレバレッジが効くポイントを見出し、その改善が最も素早く進む組織とプロダクトのアーキテクチャを同時に設計する。こうしたプロダクトと人、事業の3つを理解しながらアーキテクチャ設計することがCTOとして重要な職務の一つだと考えています。 事業とCTO先日、スタートアップ界隈を見ていて下記のも
マイクロサービスについて考えていたら疲弊したので、少し技術者らしく形式的に見てダメのものを思考から削ぎ落としたいと思った。 グラフ理論などコンピュータサイエンスの基礎を交えて話をするが、基本的には当たり前のことしか言わないと思うのでここに書くことを意識せずとも暗黙的に実践している人も多いだろう。 なお、個人の意見でしかないのであっているか間違っているかはわからないし、筆者にこの記述に反した実装を否定する意図はない。 今回は適当に書き散らかすのでかなりテイストが違うが他のブログと同一人物が書いている。乗っ取り等ではないです。 TL;DR マイクロサービスはDAGとすると考えやすいしデプロイしやすい 閉路があるなら設計を見直した方がいい DAGかどうかはサブシステムレベルでそれぞれ考えると簡単 デプロイに関係するリポジトリでは閉路がないことを意識させる設計にするといい マイクロサービスと疲弊
Infrastructure as Codeのこれまでとこれから/Infra Study Meetup #1
A method for separating policy definition and behavior control by an intermediate language to achieve optimal server configuration management according to the situation
シードデータで動作確認して大丈夫だったのに、本番反映してみたら想定してなかった挙動・エラーが出た😱そんな経験はありませんか。 恥ずかしながら私は今までに何回もありました。機能開発だけじゃなくバッチやマイグレーションなんかでも発生しがちなコレ。またはシードデータで動作確認できても、本番データでも通用するか検証ができないままプルリクを作る、なんていうこともあると思います。今回はこちらを無くす試みをしたお話です。 「もう本番DBで開発しちゃえばいいじゃない」の問題点 この課題を解決するには、極論すると本番DBで開発するしかないのですが、そうなると言うまでもなく以下の問題が出てきます。 レビュー通過してないコードが本番に影響を与える トライ＆エラーができない 個人情報をはじめとするセンシティブな情報が開発者の端末に漏れる データ量が多すぎてローカルに持ってこれない しかし言い換えると、これらをク
今押さえておくべき知識をアップデートし、ノウハウを共有し、さらなるスキルアップを実現する場として開催されている、AWS で最も Developer に特化したカンファレンス「AWS Dev Day Online Japan」。ここでSr. Product Developer Advocate, Elastic Containersの原氏が登壇。まずは、コンテナワークロード超入門として、コンテナのデプロイ時とクラッシュ時に起こることを紹介します。全3回。 自己紹介 原トリ氏：オーナーシップの塊、トリです。本日はタイトルにあるとおり、アプリケーション開発者はAmazon ECSあるいはKubernetesといったコンテナオーケストレータのことを、どこまで知るべきかについて話します。もともと「どこまで知ればいいのか」というタイトルでしたが、思いが強すぎて「知るべきか」に変わりました。 あらためて
IBMによるHashiCorpの買収が正式に発表されました。買収価格は64億ドル（1ドル150円換算で9600億円）（HashiCorpの発表、IBMの発表）。 買収交渉が行われているとの報道が昨日から行われており、それが具体化したことになります。 HashiCorp is excited to join @IBM to continue building the platform of choice for multi-cloud automation. @armon shares his thoughts on how this serves our community, customers, partners, and product innovation: https://t.co/xBIN6FkVsE (link contains important information) p
『ソフトウェア設計のトレードオフと誤り ―プログラミングの際により良い選択をするには』 Tomasz Lelek、Jon Skeet 著、渋川 よしき、山田 智子、本田 健悟、辻 大志郎、宮永 崇史、小橋 昌明、柏木 祥子、岸本 卓也、後藤 玲雄、棚井 龍之介、原木 翔、山本 力世 訳 2023年5月25日発売予定 472ページ（予定） ISBN978-4-8144-0031-7 定価4,180円（税込） 「プログラムを設計するときに行った技術的な判断や選択が、後日大きな制約となる」これはプログラマなら誰しも経験したことのあることでしょう。本書は、そんなプログラミングにおける各種の設計上の選択について、トレードオフの内容やそれがどのような誤りを招きうるのかという点を踏まえて紹介する書籍です。 コードの重複、エラーや例外処理、柔軟性と複雑性のバランスのようなコードレベルの選択から、APIの設
［速報］HashiCorpが「Terraform Cloud」機能強化、5人まで無料。チームでのクラウドインフラの管理を容易に。HashiConf '19
［速報］HashiCorpが「Terraform Cloud」機能強化、5人まで無料。チームでのクラウドインフラの管理を容易に。HashiConf '19 HashiCorpが主催する年次イベント「HashiConf '19」が9月10日（現地時間）サンフランシスコで開幕しました。 基調講演で同社共同創業者兼Co-CTOのArmon Dadgar氏は、マルチクラウドに対応するクラウドインフラのプロビジョニングツール「Terraform」のクラウド版「Terraform Cloud」の機能強化を発表しました。 Terraformは、AWSやMicrosoft Azure、VMwareなどさまざまなクラウドインフラのプロビジョニング情報を特定のインフラベンダに依存しない形式で、コードとして記述し適用できる、いわゆる「Infrastructure as Code」（IaC）を実現する代表的なソフ
追記: 振り返りを書いてみました～ -- ここから元記事 別題: 抽象化って言葉もう。。 社内の記事にて、オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) | アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章 |本 | 通販 | Amazonを紹介してもらいました。 取り上げられた、共通性／可変性分析の解説を見て、はっと思うことがありポエムを仕立てました。 共通性／可変性分析 共通性／可変性分析については、書籍を読むかググって頂けると良いですが、社内記事が良かったので引用させて頂きます。 問題領域にある概念を見つける（共通性の分析） その流動的要素を洗い出す（可変性の分析） 流動的要素を見ながら、その概念が持つ責務を果たすための抽象的側面（≒インタフェース）を導く 各流動的要素の実装上の観点から、インタフェースが適切かどうかを見極め、補正する オ
Azure App Service (Web Apps) がリリースされて 6 年、情報のアップデートを行いつつ気になった情報は適当にブログに書くという日々ですが、Regional VNET Integration や Service Endpoins が使えるようになって設計に大きな変化が出るようになったのでまとめます。 最近は Microsoft で HackFest を行うことも多いのですが、App Service をこれから使い始めたいという場合に、失敗しない構成を共有したい、知ってほしいという意図もあります。多いですが中身は単純です。 基本設定 64bit Worker は必要な場合のみ利用する FTP / Web Deploy をオフにする Always on を有効化する ARR affinity をオフにする HTTP/2 の有効化を検討する Health Checks の
エンジニア全員が Terraform を安心・安全に触れるような仕組みを整えています - VisasQ Dev Blog
はじめに こんにちは！DPE（Developer Productivity Engineering）チームの高畑です。 ちょっと前に iPhone 15 Pro に変えてようやく USB-C ケーブルに統一できる！と思っていたら、手元にある Magic Trackpad が Lightning ケーブルでしょんぼりしました。 さて今回は、ビザスクのインフラ周りで利用している Terraform をエンジニア全員が安心・安全に利用できる仕組みづくりを行なっている話をしていきます！ これまで ビザスクではインフラの構築・運用に Terraform を利用しており、依頼ベースで DPE のメンバーが Terraform の修正を行なってレビュー＆リリースをしていました。 開発メンバーから Terraform の PR をあげてもらうこともありますが、plan / apply の権限を持っていない
ソフトウェアアーキテクチャ・ハードパーツ
ソフトウェアアーキテクチャに絶対的な正解は存在しません。むしろ、さまざまな妥協点の中から選択を強いる難題、すなわち「ハードパーツ」が多く存在します。そのため、ソフトウェアアーキテクトには常にトレードオフを見極め、状況に合った選択をすることが求められます。本書は、読者が自身のアーキテクチャ上の難題に対して効果的なトレードオフ分析を行い、より良い決定ができるようにするための書籍です。 本書では、サービスの粒度やデータの所有権、コードの再利用やワークフローの調整、可用性や信頼性の実現といった現代のソフトウェアアーキテクチャの難題と、それに対するさまざまなアプローチやパターンを紹介します。そして意思決定を難しくするトレードオフについて、モノリスを分解しマイクロサービスアーキテクチャに再構築する例を通して詳しく説明します。 『ソフトウェアアーキテクチャの基礎』の著者らによる現代的なトレードオフ分析と
『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』 - snoozer05's blog
翻訳を担当した書籍『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』（オライリー・ジャパン）が明日（2024年1月24日）発売となります（電子書籍はオライリー・ジャパンのサイトでの購入となります）。本書は、2022年10月に出版されたChristian Ciceri, Dave Farley, Neal Ford, Andrew Harmel-Law, Michael Keeling, Carola Lilienthal, João Rosa, Alexander von Zitzewitz, Rene Weiss, Eoin Woods 著『Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture』（O'Reilly Media）の全
Go(Echo), Gorm, Mysql, Docker, Swaggerで、クリーンアーキテクチャなAPIサーバーを作ったメモ
自分の本業は10年物のMVCプロジェクトなのでClean Architecture忘れがちです。 なので、慣れてるGoでパッとClean Architectureの復習を行ってみました（２年前にPythonでやった事はあるんだけど・・・）。 このスクラップでは単語とか作りどころとかを整理するのですが、また後でRustで作ってそっちは前例がほぼないので記事にします。 Go + Clean Architectureは結構記事あるんですが、Swaggerつけたしたのと自分なりに納得いくディレクトリ構成にオリジナリティを出しました。ちなみにgo-swagger使うと本当は凄く楽に作れるのですが(ついでにフロントはopenapi-generator)、今回はClean Architectureを理解するのが主目的なので、サーバーは手書きでopenapiのyamlも1から自作しました。 ↑ postに
AWS SESで信頼性の高いメール送信(SPF, DKIM, DMARC) with Terraform - 電気ひつじ牧場
メール認証の仕組みと、SESでのTerraformを使った設定方法について紹介します。 メール認証の種類 メールメッセージ MAIL FROM FROM SPF(Sender Policy Framework) DKIM(DomainKeys Identified Mail) DMARC SESの設定 SESで利用するドメイン認証 DKIM設定 DMARC with DKIM DMARC with SPF 参考 メール認証の種類 メールでは送信元のなりすましを検出するための認証の仕組みとして、主に以下の3つがあります。それぞれRFCで定められています。 SPF(Sender Policy Framework) DKIM(DomainKeys Identified Mail) DMARC(Domain-based Message Authentication, Reporting, and
システムの構成を社内で共有したり外部に説明したりする際に、システム構成図を作成した経験のあるエンジニアは多いはず。ダイアグラム作成ソフト「Diagrams」を使うと、AnsibleやSubiquityといった「Infrastructure as Code(IaC)」に関連するサービスのように、プログラミング言語のPythonでコードを書くことで、クラウドやオンプレミスの構成図を描くことができます。 Diagrams · Diagram as Code https://diagrams.mingrammer.com/ まずはDiagramsの動作に必要なパッケージをインストールします。今回Diagramsのインストールに利用するのはUbuntu 18.04です。 sudo apt install -y python3 python3-pip graphviz 続いてDiagramsをインスト
クラウドネイティブを推進する約500団体が参画する CNCF (Cloud Native Computing Foundation)に、クラウドネイティブの定義が公開されている。これは、IT業界で働く者の基礎知識であると言えるので、クラウドネイティブの定義を詳細に調べた結果を以下にまとめる。 CNCFとは CNCFは2015年7月に発表され、約50社が集まり2016年1月に正式発足した。最初の発表から4年後2019年11月のメンバーは約500団体で、大手クラウド事業者、ミドルウェア企業、ハードウェア製造企業、オープンソース・ソフトウェア企業、大学、その他非営利団体などが加入している。 CNCFは、The Linux Foundationの下で運営され、クラウドとコンテナに関連する横並びの活動として、Cloud Foundry Foundation、Xen Project, Open Con
はじめに この記事はサービスを爆速で作ったり、ドメイン駆動設計の解説をするようなものではありません。 ドメイン駆動設計の勉強をしていて、手を動かす機会が足りないと感じていました。そこで、今の理解で実際に動くシステムをドメイン駆動で開発してみようと思いました。 本記事はその開発の過程や考えていたことを記録したものです。 「この人はこういう形に落とし込んだんだな～」くらいで見ていただけたらありがたいです。 作成するシステム 今回作るのはTODO管理システムです。 初回の開発では以下の機能を開発しました。 TODOのタイトルと詳細を登録できる 作成したTODOを検索できる 選択したTODOの詳細を確認、完了、削除ができる デモ デモなのでメールの確認はダミーです。新規登録をしたら画面に出るメール確認リンクを踏めば確認済みとなります。 その後右上のログインからログインしてください。 デモのデータベ
こんにちは。株式会社ペライチ のインフラエンジニア曽根です。 エンジニアたるもの常に情報収集は欠かせませんね。 最新の情報や知識は Web ニュースや Web のブログ記事などで入手できますが、腰を落ち着けて情報を吟味したり知識を学ぶためには、情報をまとめたうえに順番立て教えてくれる書籍の活用がお勧めです。 今回は、いわゆる一般的な書籍（商業誌と言います）ではなく、技術同人誌を紹介します。 技術同人誌をお勧めする理由は、ずばりエンジニアのとがった意見が聞けるからです。 商業誌と同人誌の違いはなんでしょう？ 商業誌には書籍コード（ISBM）がついている？同人誌には ISBN を持ったものもあります。 書籍コードがついていますから、同人誌でありながら一般的な書店に注文できます。 私は、商業誌と同人誌の最大の違いはプロの編集者が内容に関与するレベルの違いであると思っています。 同人誌はほとんどの
クリーンアーキテクチャで web アプリケーションを作る際に、バリデーションはどのレイヤの責務なのか？と悩むことが多いため、それについての考察を行ってみる。 あと、バリデーションについて書いてたはずがドメインロジックとアプリケーションロジックの違いについても結構言及せざるを得ない感じになったので、そのへんの話もしてみる。 結論から言うと バリデーションはどのレイヤの責務なのか？という問い自体が間違いであり、レイヤごとにそのレイヤの責務となるバリデーションを行うべき、というのが今のところの結論。 バリデーションという単語は意味があまりに広い。「意図していないもの/ことを防ぐ」ことはすべてバリデーションと呼ばれている節がある。そのことにより、バリデーションというのはあたかも唯一つの責務であるかのように錯覚しがちだが、そうではない。クリーンアーキテクチャではレイヤによって責務を分担しているが、同
本書は、初めてDDDを学ぶ方、もしくは実際に着手して「難しい！！」と感じているエンジニアの方を対象とした、ドメイン駆動設計(以下、DDD)についての解説書です。 近年、ソフトウェアのレガシー化が社会的に問題になっていると言われています。 DDDはレガシー化への対策として非常に有用なものですが、日本語で出ている書籍「エリック・エヴァンスのドメイン駆動設計」や「実践ドメイン駆動設計」は非常に重厚かつ難解で、初学者が実用に到達するまでには長い時間と試行錯誤が必要なのが実情です。 そこで本書では、迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、 具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。 また、その後にはレイヤーごとの個別のトピックについて、1章ずつ詳しく解説します。 ■本書の構成 本書は以下の構成になっています。 「第1章 DD
たびたびTweetしておりますが、2019年9月22日の技術書典7に、『AWSの薄い本 IAMのマニアックな話』という本を出展します。名前の通りAWS本ですが、IAMだけを取り扱っています。初の同人誌を引っさげて、技術書典デビューします。 IAM本の目的 書いた本はIAMの特化本ですが、何故IAMと聞かれるのでここに書いておきます。AWSが不正利用されて100万円の請求が来たというようなニュースが、たまにネットを駆け巡ることがあります。原因の多くがIAMのアクセスキーをGitHubに誤ってコミットしてしまい、そのキーを不正利用されたケースです。そういった事態を防ぐために正しくIAMを知って貰いたいのです。 IAMは、AWSの利用権限を管理する極めて重要な機能です。AWSには多種多様な機能があり、IAMはそれに応じて様々な記述方法で権限を設定できるようになっています。その分設定項目が多く、I
ここまで読んでくださった皆さんに、ちょっとしたクリスマスプレゼント。マンガでわかる GoF デザインパターン 23 種チートシートです。これでもうデザインパターンは完全にマスターしましたよ。やったね! (注: ここからはあとがきポエムです) ところでみなさん、せっかくデザインパターンを学んだので、これを使ってプログラムを書こう、チートシートがあるからなんでも書けそうだぞ、なんて思っていませんか。ダメですよ。そんなことしたら 2000 年前後に起きた失敗を繰り返してしまいます。 実は GoF のデザインパターンは、ビジネス的には成功したけど、教育には失敗しました。最初に出版された本に「オブジェクト指向における再利用のための」という肩書が付いていましたが、これが本当に良くなかった。 あの頃 (ポール・グレアムが LISP と Ruby を褒めるまで) は、「オブジェクト指向様こそが良い設計のす
HashiCorpのミッチェル・ハシモト氏がCTOを退任、今後はフルタイムの開発者として貢献していくと発表 HashiCorpの創業者の一人として知られるミッチェル・ハシモト氏は、同社のCTOおよび経営陣からの退任を発表。HashiCorpには残り、社員の立場でフルタイム開発者として貢献していくとのことです。 I've decided to become a full-time individual contributor at HashiCorp and will no longer be an exec. This is something we've planned for years and I'm so happy HashiCorp is in a place to allow it to happen. Do what you love, not what others ex
DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡です。 本記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、本記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p
![DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/e19eb6aae8a33a9c7d58ab11012b9b1e4fd3dc14/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20210306%2F20210306230551.png)
HashiCorp「Waypoint」発表。環境やプラットフォームの違いを吸収してコマンド一発でビルド、デプロイ、リリースを実行
HashiCorp「Waypoint」発表。環境やプラットフォームの違いを吸収してコマンド一発でビルド、デプロイ、リリースを実行 HashiCorpは新しいオープンソースプロジェクト「Waypoint」を発表しました。 Introducing HashiCorp Waypoint, a new open source project providing consistent developer workflows to build, deploy, and release applications across any platform #HashiConf #WaypointUp Learn more: https://t.co/l1LPgph9tA pic.twitter.com/PoSIrz4xXo — HashiCorp (@HashiCorp) October 15, 2020
StackScript、k8s、Terraformを使って、Linodeで負荷試験環境を自動で構築する方法について、アカマイ・テクノロジーズの岡本英輝氏と佐藤裕行氏が、実際のデモを交えて紹介しました。後半はLinodeを使った負荷試験のデモとQ&Aについて。前半はこちら。 Linodeのメリットが得られやすいユースケースとは？ 佐藤裕行氏（以下、佐藤）：後半は、Linodeのユースケースについて、少し岡本さんと話を進めていきたいと思うんですけども。今回はアプリケーションの負荷試験にフォーカスして、デモなども見せていきます。 その前に、負荷試験以外のサービスでいうと、こういうのに向いているとか、こういうのに向いてそうなところって、なにか感覚として持ってたりしますか？ 岡本英輝氏（以下、岡本）：前半に続いて、ちょっと転送量コストの話ばっかりになってしまうんですけど、やはりアウトバウンド転送量を
【Atomic Designに懐疑的なあなたへ】改めて考えたい React / Next.js のデザインパターン
フロントエンド開発は一般的に複雑性との戦いです。放ったらかしにしておくとますます複雑になり、変更するのが難しくなります。これまでにも、このような複雑さをどうにかして制御しようとして、Atomic Designをはじめとした様々な設計手法（デザインパターン）が考えられてきました。 しかし、React / Next.js を使ってチーム開発を行う際に、現状のデザインパターンでの運用では「どうもうまくいかないな」と思う場面に多々遭遇しました。そのような経験を踏まえて、「コンポーネントをどのように設計するか」「どのようにディレクトリを分けるか」を徹底的に考え、新しいデザインパターン「Tree Design」にまとめました。 Tree Design はまだまだ仮説段階です。今後弊社チームで運用していく中でブラッシュアップする予定です。しかし、他のフロントエンド開発チームがデザインパターンを再考する際
本日(1月18日)発売された、Software Design誌 2023年2月号の第一特集で「ドメイン駆動設計入門」を書きました。 執筆の意図と記事の概要を簡単にまとめておきます。 Software Design 2023年2月号｜技術評論社 執筆の意図 特集のサブタイトルにある通り「設計力を磨きたい」読者が、ドメイン駆動設計の基礎を知ることで「設計の手法とアイデアの引き出し」を増やすことの役に立てればと思い執筆を引き受けました。 重視したこと 断片的な用語やパターンの解説でなく、ドメイン駆動設計の全体像と要点を伝える 全体像を伝えるための図や表を多めにした（ソースコードの例は少ない） 全体像と要点は、原典である『エリック・エヴァンスのドメイン駆動設計』（以下『ドメイン駆動設計』）の説明を中心にした ドメイン駆動設計の具体例として『ドメイン駆動設計』に出てくる国際海上貨物輸送の具体的な業務
限られた人数で MIXI のあらゆる公式サイト群を保守・運用する ノウハウとその体制 | MIXI SRE秋祭り 〜 MIXIのもうひとつのSRE 〜
2023年10月31日に株式会社MIXIで行われた「MIXI SRE秋祭り 〜 MIXIのもうひとつのSRE 〜」での発表資料です。 イベントページ https://mixi.connpass.com/event/299121/ ─────────────── MIXIのSREは、サービスの信頼性に直接関わる負荷やコスト、システムの信頼性などをサービス開発と密接に連携しながら取り組むようなSREと、社内の共通課題やスポットで相談された事業などへの技術支援など、全社的なサービスの信頼性に関わるありとあらゆることに取り組むSREがいます。 本イベントでは、後者の全社的なサービスの信頼性に関わるSREから、最近の取り組み事例を紹介させていただき、Q&Aの時間などを通して、ご参加の皆様と共に情報交換ができれば幸いです。 ◎こんな方におすすめ◎ ・SREとしてサイト信頼性だけでなく、企画や事業開発な
Infrastructure as Code の静的テスト戦略 #DevOpsDaysTokyo / DevOpsDays Tokyo 2021
DevOpsDays Tokyo 2021 で使用したスライドです。 Infrastructure as Code を導入してみたはいいけれど、デプロイしてみたらなぜか上手く動かない。そんな経験はありませんか？ 本セッションでは、実際の環境を構築する「前」に、IaC のコード自体に対してテストを行う手法について解説します。 ご存知の通り Infrastructure as Code (IaC) は、インフラをコードで定義することを通し、アプリケーション開発のベストプラクティスをインフラ領域にも輸入しようとする方法論です。IaC の考え方は近年急速に普及し、開発フローの一部として種々の IaC ツールを利用することは半ば常識のような状態にあります。 しかし同時に、IaC は銀の弾丸ではありません。特に組織的な導入を考えようとすると、得てして「なぜか上手くいかない」「余計に運用が辛くなってしま
DDDにおける値オブジェクトの位置付け(モデルとコード事例あり)[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 最近、値オブジェクトに関して書かれているブログ記事を見ますが、 SNSなどにおいてDDDにおける値オブジェクトについて誤解されているような反応が見受けられました。 そこで、この記事では「DDDにおける値オブジェクトの位置付け」について解説し、具体的なモデル・コードを用いながら誤解を解いていきたいと思います。 なお、値オブジェクトに関する詳細な説明はここでは行いませんのでご了承下さい。 DDDの目的 まず最初に、DDDの目的について確認します。 DDDの目的は、モデリングを通じてソフトウェアの価値を大きくすることです。 これに関しては、こちらの記事で詳細に解説しているのでこちらをご覧ください。 ドメイン駆動設計は何を解決しようとしているのか - little hands' lab ここで大切なのは、モデルは一回のモデリングで完成形
![DDDにおける値オブジェクトの位置付け(モデルとコード事例あり)[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/d6ececc2d05edbf2c4b45bcb603bdecda34fde46/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20220815%2F20220815005816.png)
OpenTofu
Truly open-sourceunder a well-known and widely-accepted license that companies can trust, that won’t suddenly change in the future, and isn’t subject to the whims of a single vendor. Community-drivenso that the community governs the project for the community, where pull requests are regularly reviewed and accepted on their merit.
（6/22 注：書き足りないと思っていた箇所を補って加筆修正しました） エンジニアのbonotakeです。Ideinに入ってかれこれ3年以上経ちますが、Ideinでブログ記事を書くのは初めてです。 今日は、ソフトウェア設計の全く新しい考え方について書かれた "The Essence of Software" という本の紹介をしたいと思います。 この本の著者はMIT教授でソフトウェア工学の世界的な研究者であるDaniel Jacksonです。形式手法Alloyの発明者、と言ったほうが通じる人には通じるかもしれません。形式手法とは、ありていにいえば、数理論理学を駆使してソフトウェアに潜むバグを論理的に駆逐する手法です。 （個人的な宣伝ですが、彼の書いたAlloyの本を以前翻訳して出版しました。） そんな彼が昨年11月に新著を出版したというので、ほぼその日に買いました。……ですが、本を開いてみる
DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 ドメイン層のオブジェクトを設計する際に、重要な基本方針があります。 ドメインモデルの知識を対応するオブジェクトに書く 常に正しいインスタンスしか存在させない この2つを守ると、非常に保守性の高いコードにすることができます。 以下、詳細に解説します。 ドメインモデルの知識を対応するオブジェクトに書く ドメイン知識(ルール/制約)を表現する実装を、ドメイン層のオブジェクトに寄せていきます。 この判断は、「ドメインモデル図に書かれた吹き出しの内容が、どの層で実装されているか」という基準に基づき行います。 この基準はコード設計の指針として非常に役立ちます。 設計の良し悪しというのはさまざまな基準があるため、レビューをしていてもいわゆる「俺の考えた最強の設計」同士が戦ってしまうことがあります。 しかし、「ドメイン知識はドメイン層に書く」と
![DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/cf7c2977c5538fe370d1ff60a78958464a9e1f3f/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20220125%2F20220125074432.png)
DDDを実践するための手引き（概論・導入編）
ナニコレ DDDは「Domain-Driven Design（ドメイン駆動設計）」の略語で、エリック・エヴァンスさんという人が考えるソフトウェア設計におけるプラクティスまとめみたいなものです。 『エリック・エヴァンスのドメイン駆動設計』というバイブル的な書籍がありますが、「途中で挫折した」「読んでもよくわからない」「よくわからないけど自分なりに解釈して実践している」というような感想をよく聞きます[1]。DDDの概念は幅広く、哲学的で、抽象的であるため、DDDをどのように解釈しどのように実践すればいいのかわかりにくいものです。 この記事ではそのような問題に悩んでいる人たちのために、数年に渡りDDD（的なもの）を実践してきた筆者が噛み砕いた（個人の独断的な）解釈と実践方法を解説します。 DDDってなぁに？ DDDがカバーする領域 DDDが言及する範囲はとても幅広いです。エリック・エヴァンスさん
リクルートのAWS基盤におけるTerraform運用_実践的な取り組みと組織づくり / HashiCorpVirtualStrategyDay_sudo
2022/04/21_HashiCorp Virtual Strategy Day Japan Vol.2での、須藤の講演資料になります
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CTOの大切な役割の一つ｜Matsumoto Yuki
マイクロサービスを形式的に見てみる - Juju-62q's blog
毎日本番DBをダンプして、ローカルと開発環境で利用して生産性を上げてる話
アプリケーション開発者はどこまで知っているべきなのか？ 前提知識整理のための、コンテナワークロード超入門
［速報］IBMによるHashiCorpの買収が正式発表、マルチクラウドの自動化を加速させると
5月新刊情報『ソフトウェア設計のトレードオフと誤り』
オブジェクト指向プログラミングは終わった - Qiita
後悔しないための Azure App Service 設計パターン (2020 年版) - しばやん雑記
Pythonでコードを書いてAWSやKubernetesのシステム構成図を出力できる「Diagrams」
IT業界で働く者の基礎知識となるクラウドネイティブ とは？ - Qiita
とにかくドメイン駆動設計を実践してみる試み ～TODO管理システム編～
エンジニアなら読んで損なし技術同人書9選（インフラより）
Clean Architectureにおいてバリデーションはどこでやるべきか
ドメイン駆動設計 モデリング/実装ガイド - little-hands - BOOTH
#技術書典 に出展する『AWSの薄い本 IAMのマニアックな話』はこんな本 - プログラマでありたい
GoF デザインパターン チートシート - Qiita
HashiCorpのミッチェル・ハシモト氏がCTOを退任、今後はフルタイムの開発者として貢献していくと発表
“わずか10分”で「負荷試験環境」の構築が可能に クイックにチェックできる状況をサクッと作れる、Linode活用法
『ドメイン駆動設計』の解説記事を書きました - ソフトウェア設計を考える
"The Essence of Software"が提唱する全く新しいソフトウェア設計の考え方｜Idein株式会社