実践！ Typescript で DDD - マイクロサービス設計のすすめ - Leverages Tech Blog
対象読者 マイクロサービス化を検討しており、実際に作る場合の構成を参考にしたい。 ドメイン駆動設計について、基本的な用語の知識がある。 TypeScript を多少触ったことがある。理解がある。 はじめに こんにちは。エンジニアの吉村です。 現在、弊社が運営する teratail というサービスに携わっており、CakePHP で動作しているモノリシックな既存サービスをマイクロサービスに移行するというプロジェクトを進行中です。 この記事では、実務を通して得た知見として、マイクロサービス化によりどんな恩恵があるのか、具体的にどのような構成で実装をしているのかについてご紹介します。 TL;DR マイクロサービスのバックエンドサービスの実装に焦点を絞って、ドメイン駆動設計 + オニオンアーキテクチャをベースに設計をしました。 本記事では、具体的に「ユーザ新規登録処理」の実装をする場合を例にとり、実
バックエンド Web API に管理画面/管理機能を追加するアーキテクチャパターン - valid,invalid
プレゼンテーションレイヤ、いわゆるフロントエンドがクライアントサイドで実装・実行されるアーキテクチャ (注 1) において、管理画面/管理機能をあとから追加する際にどのような実装パターンがあるのかを整理してみます。 注 1: Presentation Domain Separation の実践の中でも、物理的にプレゼンテーションロジックとドメインロジックを分離しているアーキテクチャです。 用語の整理 プレゼンテーションレイヤ 三層アーキテクチャにおける、システムの利用者へユーザインターフェイスを提供する層です。本記事では"フロントエンド"とほぼ同義で使います。 OSI 参照モデルの第六層ではないです。 バックエンド Web API とは プレゼンテーションを持たない Web API (HTTP プロトコルを用いてネットワーク越しに呼び出すアプリケーション) とします。 プレゼンテーションレ
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer
UI改善のためにエンジニアに仕様を構造化してもらったら再設計がめちゃくちゃ捗った話｜鈴木 健一 / PLAID & Ex.STANDARD
この記事はPLAID Advent Calendar 9日目の記事ですUI改善の前提理解、うまくできていますか？皆さんはこれまで着手してこなかった既存画面のデザイン改善をする時、どのように進めているでしょうか。 自分がプレイドで所属しているreBAISUというチームでは、タタキとして定義したスタイルガイドを旧来の画面に適用しながらUI改善する取り組みをしています。 取り組み方として、改善対象となる画面の仕様を理解しながら課題を見つけ、解決策を検討していく流れになるのですが、この仕様理解が難しいと感じていまして。 なんとか前提理解を促せる方法はないものかと検討した結果、対象画面の構成要素をひとつずつ紐解いていく方法で理解していく「デザインの逆行分析」という方法をとっていました。 デザインの逆行分析とは「リバースエンジニアリング」とも呼ばれる手法で、その考えをデザインでも応用しようというもので
「Amazonでさえサーバレスやマイクロサービスを理解できない」とDHH氏が主張する一方で、「進化可能なアーキテクチャこそ重要」とAmazonのVogels博士
Ruby on Railsの作者として知られるDavid Heinemeier Hansson（DHH）氏が自身のブログに5月4日付けで投稿した記事「Even Amazon can't make sense of serverless or microservices」（Amazonでさえサーバレスやマイクロサービスを理解できない）が話題になっています。 これはAmazon Prime Videoの技術部門が3月に自社ブログに投稿した記事「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」（Prime Videoの音声映像監視サービスにおけるスケールアップと90％のコスト削減の実現）で紹介された、AWS Lambdaのサーバレスで作られたPrime Videoの監視サービス
2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て
監視について思うとこ - y-ohgi's blog
TL;DR 監視はユーザーにサービスを提供できているかを観測するための行為 SLI/SLOを定めて、SLOを守れるようにモニタリングする ダッシュボードは定常的に表示しておくものと障害時に活用するものを作ると良い アラートはレベル分けして人間が対応しなければならないものだけ人間へ通知する 監視とは サービスを健全に動作させ続けるために監視を行います。 「健全に動作している」の定義はサービスによって異なり、ユーザーにWebページを見せることができることだったり、バッチが正常に終了することだったりします。 最終的にユーザーに正常にサービスを提供できていることを観測するために行うことに変わりはありません。 さてユーザーにサービスを提供するために何を監視しましょうか？ クラウド前提であれば個人的にリソースベース（CPU/Memory）より、 SLI/SLOをベース に監視する事が望ましいと考えてい
こんにちは、開発チームのアーキテクトをやっている竹野（@Altech）です。先日、新人研修でソフトウェアの設計について話す機会がありました。 ソフトウェアの設計というのは関連する領域が広いため、どうしても断片的な理解になりがちです。そこで、早い段階で全体像を感じてもらうために、ソフトウェア設計の Why と How と What を1時間でまとめて話すというちょっと意欲的なコンセプトで研修を行いました。今回は、その内容を記事にしました。 この研修のねらいはじめにソフトウェアの設計について書かれた情報は世の中に多いですが、その情報の多くは How であり、それだけを読んで適切に使うことが難しいと感じています。その直接的な理由は、How に対しての What、How / What に対しての Why が語られることが少ないからです。 ただ、How だけを知っていると、それは本当に問題を解決して
「オブジェクト指向神話からの脱却」という特集をWEB+DB PRESSで書きました - きしだのHatena
「オブジェクト指向神話からの脱却」というあおり気味タイトルの特集をWEB+DB PRESS vol.132で書きました。 12/24発売！クリスマスプレゼントです WEB+DB PRESS Vol.132 作者:きしだ なおき,加藤 尋樹,斉藤 洸紀,牟田 裕太郎,吉澤 政洋,朝日 リナ,鈴木 僚太（うひょ）,川島 義隆,五十嵐 進士,末永 恭正,佐藤 雄太,吉井 健文,牧 大輔,西山 和広,吉田 花春,古川 雅大,岡林 大,池澤 春菜,和田卓人,日高 正博,はまちや2,竹原技術評論社Amazon 大まかには、「オブジェクト」でソフトウェアをぜんぶ考えるということに無理があったので、パーツそれぞれ適したやりかたでやっていこうぜ！という内容です。 ソフトウェアを切り出したときのパーツとしてのオブジェクトの特性が同質であるという暗黙の前提があって、だから「オブジェクトの話をすればソフトウェア開
ソフトウェア設計のトレードオフと誤り
「プログラムを設計するときに行った技術的な判断や選択が、後日大きな制約となる」これはプログラマなら誰しも経験したことのあることでしょう。本書は、そんなプログラミングにおける各種の設計上の選択について、トレードオフの内容やそれがどのような誤りを招きうるのかという点を踏まえて紹介する書籍です。 コードの重複、エラーや例外処理、柔軟性と複雑性のバランスのようなコードレベルの選択から、APIの設計、時刻の扱い、データローカリティのようなシステム寄りの話題、またライブラリの選択、分散システムの一貫性と原子性、バージョニングのようなより抽象度の高い内容まで、さまざまなシチュエーションにおけるトレードオフの実態と、その失敗例をとり上げます。 本書は日々のプログラミングにおける解決策のヒントを得るだけでなく、より幅広い設計上の知見を広める上でも役に立つでしょう。 正誤表 ここで紹介する正誤表には、書籍発行
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
色々な原則や方法論はあれど、つまるところいかに変更容易性を確保するかと言う話に帰結するのでは。極論すれは、正しく動いていて変更する必要が無ければどのような作りになっていても構わない。一方、Web アプリケーションを稼働し続ける上で全く変更しなくて良いということもない。— Masashi Shinbara (@shin1x1) 2021年5月30日 ソフトウェア設計、開発には多くの原則や方法論がある。例えば、DRY 原則や SOLID 原則、デザインパターンにレイヤードアーキテクチャ、クリーンアーキテクチャなどある。さらに DDD にも多くの原則や方法論が含まれている。これらを変更容易性を高めるための手段として原則や方法論を捉えるというのが本エントリの論旨である。 原則や方法論の捉え方 変更容易性 本質的な変更と副次的な変更 外部変更容易性と内部変更容易性 原則を適用する指針 さいごに 原則
型駆動設計から始まるフォーマルなアプローチもカバーしているが、フォーマルな方法の簡単な紹介も含まれているもの。
「ソフトウェアアーキテクチャの基礎」読書感想
2010年代を乗り越えてきた経験者が読むと良さそうという噂を聞いたので読んでみた。 内容まとめではなく感想です。各章のタイトルだけは丸々記載してますが、目次として上記ページで全て公開されているものです。 ちなみにこれ書いている私はソフトウェアアーキテクトではなく、フロントエンドアプリケーションの設計を担当するテックリードぐらいのレイヤーです。この書籍の中でいう「開発者」です。 業務ではフロントエンドアプリケーションの設計・実装をしています。 全体的な感想 1章（イントロダクション）、22章（効果的なチームにする）、23章（交渉とリーダーシップのスキル）が特によかった。 やっぱ "結局人" の部分が刺さってしまう。 心に書きとめておきたい3つを挙げるとしたら以下。 ソフトウェアアーキテクチャとは「構造」「アーキテクチャ特性」「アーキテクチャ決定」「設計指針」の4つから成る 「一見どう見えよう
技術部の青木峰郎です。 去年までは主にデータ分析システムの構築を担当していましたが、 最近はなぜかレシピサービスのサービス開発をやっています。 今日は、そのサービス開発をする過程で導入したBFF（Backends for Frontends）であるOrchaについて、 導入の動機と実装の詳細をお話しします。 Orcha導入にいたる経緯 まずはOrcha導入までの経緯、動機からお話ししましょう。 最初のきっかけは、わたしが去年から参加しているブックマークのようなサービスの開発プロジェクトでした。 このプロジェクトの実装のために新しいmicroserviceを追加することになったのですが、 そのときにいくつかの要望（制約）がありました。 1つめは、撤退するとなったときに、すぐに、きれいに撤退できること。 2つめが、スマホアプリからのAPI呼び出し回数はできるだけ増やしたくない、という要望です。
Google、モノリスとマイクロサービスのいいとこ取りをする「Service Weaver」フレームワークをオープンソースで公開
Google、モノリスとマイクロサービスのいいとこ取りをする「Service Weaver」フレームワークをオープンソースで公開 Googleは分散アプリケーションの開発とデプロイを容易にするフレームワーク「Service Weaver」をオープンソースで公開しました。 Introducing Service Weaver! Service Weaver is an open source framework for building and deploying distributed applications. It allows you to write your application as a modular monolith and deploy as a set of microservices. Learn more → https://t.co/XmnVALYXNC pic
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
弁護士ドットコムサービスでモノリスをマイクロサービス化しようとして失敗した原因を振り返る - 弁護士ドットコム株式会社 Creators’ blog
初めまして。弁護士ドットコム株式会社でエンジニアをやっている井出です。 弊社は 2022 年 2 月から Creator's Blog を始めております。 その記念すべき最初の記事として 弁護士ドットコムサービスのビジネスと共にみるマイクロサービスの進化 を投稿いたしました。 こちらの記事で弊社がマイクロサービス化に挑戦したこと、その後の課題をどう解決していったかについて分かりやすくまとめられておりますので、ぜひ一読してから今回の記事を読んでみていただければと思います。 さて、上記記事内でも触れられているとおりマイクロサービス化プロジェクトである Gavel プロジェクトでは様々な課題が出てきました。 今回はその中の 1 つである、 ビジネス分析が不十分で一部のサービス境界が想定と異なり、開発速度が低下 について、何をどう間違え、なぜ開発速度が低下したのかについて振り返ります。 もしこれか
ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える
『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう
※追記あり。最後の追記は 2021/04/25 21:40頃※ タイトルの通りのことを思っているけど、顕名のブログで書くと社内で干されるので、増田に書く。社内の心理的安全性がそんなに低い訳ではないけども、潮流が凄いので今は慎重に振る舞いたい。 この記事を見て「キミはDDDのことを誤解している」と思われた方はコメント等で優しく（易しく、ではない）ご指摘願いたい。 ※この記事では Web Application を前提とした話になっている。 DDDとは？https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88 DDD、ここがイケてる ソフトウェア開発者は開発対象のドメインのことをほとんど知らない、という問題意識およびその提起。 俗に言う「ビジネスサ
ミラティブのサーバサイドをGo + Clean Architectureに再設計した話 - Mirrativ Tech Blog
こんにちは、テックリードの夏です。 今年4月にCTOからテックリードに肩書が変わり、ガリガリコードを書くようになりました。 背景については、こちらをご覧ください。 www.wantedly.com 普段はプロダクト側の機能開発と、サーバ側の基盤開発を半々ぐらいの割合で仕事しています。 一口にサーバ側の基盤開発といっても定義が曖昧なのですが、基本的にはこんな感じのタスクをやっています。 インフラコストの最適化 不正なアクセスからの防御 障害の再発防止 新技術の導入やアーキテクチャの整備 今回はこのうち「新技術の導入やアーキテクチャの整備」の中で、サーバサイドをGo + Clean Architectureで再設計したことについてお話したいと思います。 背景 ミラティブは2015年春頃に開発が始まり、同年8月にサービスがリリースされ、2020年8月で5周年を迎えました。 その過程で組織やプロダ
アジャイル迷子のための「アジャイルの本質」。あとDDDとのつながり - little hands' lab
記事の構成 アジャイルソフトウェア開発とは アジャイルマニフェストとは アジャイルマニフェストの問題 そこで、アジャイルの本質 by マーティンファウラー アジャイルソフトウェア開発とは？ アジャイルソフトウェア開発とはなんでしょうか？ 「アジャイルマニフェスト(後述)の4つの価値観、12の原則に従う開発方法の総称」 これが最もオリジナルな定義です。 なぜこんなややこしい言い回しをするのは後から説明します。 重要なことは、「アジャイル」という具体的な手法があるわけではないということです。 アジャイルはマインドセット(思想、考え方)です。そのため、 ✖️ do agile 「アジャイルをやる」はありません。 ⭕️ be agile 「アジャイルになる、アジャイルの思想に則る」はあります。 アジャイルの思想に則った開発手法として ・スクラム ・エクストリームプログラミング(XP) ・リーンスタ
Rustのメモリ管理機能とその特徴
初出：技術評論社刊「ソフトウェアデザイン 2021年9月号」 先日、技術評論社よりRustのメモリ管理機能についての特集に寄稿させて頂きました。 この記事は自分が寄稿させていただいた記事をブログ用に一部推敲・加筆を加えたものです。 なお、ソフトウェアデザインでの特集ではより実践的な例でのメモリ管理についての解説もあるので、興味のある方は本誌のほうも手にとっていただければと思います。 プログラム言語におけるメモリ管理の課題プログラミングにおける課題の一つとしてどうやってメモリ領域（ヒープ領域）を管理するかというものがあります。 C言語ではmalloc/free関数などを用いて手動でメモリを管理しています。 これらの関数はメモリアドレスを示すポインタを介してメモリ管理を行います。 malloc関数は必要なメモリ領域を確保してその先頭番地のポインタを返し、プログラム内ではその番地のメモリを読み書
ホテルの客室検索APIのアーキテクチャ設計時に考えたこと
作ったもののイメージ ホテルの客室検索APIとは、チェックイン日やその他の条件を入力として受け取り、マッチするホテルの客室を返すものです。以下の画像はExpediaのものですが、赤枠で囲っている部分（他にもたくさんある）が入力になります。2022年4月頃に無事リリースされました。 この検索APIを構築を任された際に、何を考えて設計していったのかを以下に示していきます。 顧客からの要望 顧客の会社は当時エンジニアがおらず（やりとりしている社長は元エンジニアだが）、これまでも私と仕事をしたことがあったので依頼が来ました。顧客と密にコミュニケーションを取りわかったのは、以下のような要望でした。 このAPIは自社サービスとして第3者（要契約）に使ってもらえるようにしたい 完全に一般公開ではなくちゃんと契約を結ばないと利用できないようなもの 検索条件を柔軟に、かつ使いやすい感じで指定できるようにした
Software Design連載 2021年8月号 Python製のレガシー＆大規模システムをどうリファクタリングするか - MonotaRO Tech Blog
Software Design連載開始 ※ (2021/09/02 08:55) 「Pythonを用いて開発を始めたのが2003年」を「Pythonを用いて開発を始めたのが2002年」に修正 こんにちは。金谷です。 このたび、モノタロウにおけるPython大規模開発に関する取り組みを、技術評論社様で発刊されている Software Design に連載させていただくことになりました。 モノタロウがPythonを用いて開発を始めたのが2002年。2021年の現在もPythonを用いた開発が続けられています。 事業の成長に伴い、関連するシステムやエンジニアの数も増え続けていくなかで、いかに安定的に価値を提供し続けられるのか。 モノタロウにおける取り組みを、開発や運用周りを通してご紹介していきます。 本記事の初出は、 Software Design2021年8月号「Pythonモダン化計画（第1
こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提 〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継
近年、デジタル化政策を次々と推し進め、世界の中でも最前線を行く「電子国家」として日本でも有名になっている、人口わずか130万人の小国がある。それがエストニアである。 「e-government」と呼ばれる国民データベースにより、国民はICチップ付きIDカードによって全ての行政サービスを受けることができる。また国民の96%がインターネット上で所得税申告を行うなど、行政インフラのIT化が進んでいる。現在では「eResidency」という制度によって世界中の人々に「virtual国籍」を発行するというユニークな政策も行なっている国である。まるで国全体がスタートアップ組織のようだ。 しかし、国が打ち出す電子国家としてのイメージとは裏腹に、実際には多くの人がいまだに現金を使っていたり、ネット投票を利用していなかったりと、後進的な部分もまだまだ残っている。だからこそ、この先エストニアという小国がどのよ
モノリス分割はこうやる！「How to break a Monolith into Microservices」を読んだ - kakakakakku blog
研修中に「マイクロサービス」の解説をしていると，たまに「モノリス分割」に関する質問が出てディスカッションをすることがある．当然ながら万能な分割アプローチはないけど，例えば DDD (Domain-driven design) などのアプローチを選択するなど，選択肢はいろいろある．そして最近「モノリス分割」に役立つアプローチを紹介した martinfowler.com の記事「How to break a Monolith into Microservices」を読んだ． 具体的には以下の「計8種類」のアプローチが紹介されている．原著を翻訳するのではなく，あくまで個人的なメモとしてまとめる．なお，日本語も個人的に載せているため，参考程度にしてもらればと！ Warm Up with a Simple and Fairly Decoupled Capability（シンプルかつ分離された機能で準
こんにちは。X（クロス）イノベーション本部 ソフトウェアデザインセンター セキュリティグループの耿です。 AWS WAF は簡単に Web アプリに WAF を追加でき、かつ値段も他の WAF 製品より安いため、好きな AWS サービスの一つです。そんな AWS WAF ですがしばらく構築・運用し、これを最初から知っておけば・・・と思ったことがあるので 8つご紹介します。 AWS WAF の基本については分かっている前提で、特に説明はいたしません。また2023年10月現在の最新バージョンである、いわゆる「AWS WAF v2」を対象としています。 その1: AWS マネージドルールのボディサイズ制限が厳しい その2: ファイルアップロードが AWS マネージドルールの XSS に引っかかることがある その3: マネージドルールにはバージョンがある その4: CloudWatch Logs
AWS、言語やプロトコルに依存しないインターフェイス定義言語（IDL）「Smithy」をオープンソースで公開
AWS、言語やプロトコルに依存しないインターフェイス定義言語（IDL）「Smithy」をオープンソースで公開 クラウド時代のアプリケーションは、複数のソフトウェアがAPIを通じて連携するアーキテクチャが主流になると考えられています。そのため、さまざまなソフトウェアにおいて正確かつ確実にAPIを実装することの重要性が高まっています。 AWSは、このAPIを定義する言語、およびその定義からAPIを実装するコードを生成するツールからなる「Smithy」ベータ版をオープンソースとして公開しました。 SmithyのWebサイトから、その説明を引用しましょう。 Smithy is a protocol-agnostic interface definition language and set of tools for building clients, servers, and documentat
TDD についておさらいしておきたいなと思ったので読んだ t-wada.hatenablog.jp とても良かった。自動テスト、テストファースト、テスト駆動開発のそれぞれについて、どういうものなのか・効果・注意点が分かりやすく説明されている。たしかに、自動テストは必ず使うけど、テストファーストやテスト駆動開発は状況に合わせてやったりやらなかったりする 書籍「テスト駆動開発」の付録Cと対になっているということなので、付録Cも読みたくなって読み直しておいた。そちらにはテスト駆動開発のこれまでとこれからについて書いてあるので、頭の整理ができてとてもよかった Checking Driven Development 付録Cでは、開発者自身が書く自動テストはテストではなくてチェック、ということについて触れられている。そうだなぁって思う。自動テストでは、自分が考えたとおりに動くかどうかをチェックしている
上の資料でも書いてるんですが、要点を言うと以下のようなことを主張している。 API の設計手法として、以下の2つのパターンが考えられる ・Resource-based API ・Usecase-based API Usecase-based というのは要はクライアントの要求にそのまま沿った形で API を作るということだ。しかし、UI やその他クライアントの要求というのは変わりやすいものなので、そのたびにいちいち API を変更しないといけないとか、API に一貫性がなくて使いにくいとか、1つの endpoint で多数の要求に対処する "神API" が作られてパフォーマンスが悪化する、というような問題が起こる。 したがって、注意深く RESTful API を設計すると Resource-based になる。ここで言っている Resource というのはテーブル設計にやや近いが、そのまま
Merpay Advent Calendar 2019 の19日目は、Backendエンジニアチームの @toshinao がお送りします。 新しくマイクロサービスを立ち上げる機会があり、クリーンアーキテクチャをベースにしました。クリーンアーキテクチャはバックエンド・フロントエンド・アプリなど様々な場所で採用されています。ただ、確固たる方法というのは無く、みな試行錯誤しているのでは無いでしょうか。この記事では、クリーンアーキテクチャを取り入れる上で考えたことを紹介したいと思います。 マイクロサービスを作ったことがない人や、今までいくつか作ってきたけどより良い設計について考えている人の助けになれば幸いです。 はじめに メルペイのバックエンドは主にGoとGoogle Cloud Platform（GCP）で開発を行っていますが、各マイクロサービスをどう実装していくかは概ね各チームに委ねられてい
【続】ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに 本記事は前回の記事である「ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog」の続編です。 前回の記事の内容がベースとなっていますので、「APoSD って何だっけ？」という場合はぜひ前回の記事をご覧になってから、以下にお進みください。 ということで、後編の対話パートにさっそく入っていきましょう！ Pull Complexity Downwards iwashi: APoSD では、複雑性を下に追いやる(Pull Complexity Downwards)という話が出てきます。何らかの処理が複雑になる場合、それを隠蔽してインターフェースを極力シンプルに保つ、というのがAPoSDの主張です。 こちらに関しても、社内勉強会中で
『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』は、現代ソフトウェア開発の”知の高速道路” - Magnolia Tech
ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用 作者:田中 ひさてる技術評論社Amazon 予約してまで買ったものの、なかなか時間が取れず、読めていなかった『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』をようやく読み終わりました。 筆者である田中ひさてるさん自身で描かれた表紙の可愛らしさからは想像もできないハードな内容なので、一気に読もうとすると「分かった気」になるだけで全然理解していなかった、ということになりがちなので、3回くらいぐるぐる読むといいと思います（そうです、この本は本文もイラストも丸っと同じ人が書いているのです！！）。 目次 第1章 クリーンアーキテクチャ 第2章 パッケージ原則 第3章 オブジェクト指向 第4章 UML（統一モデリング言語） 第5章 オブジェクト指向原則 SOLID 第6章 テスト駆動開発 第7章 依存
「.NET Core 3.0」正式版が登場。Windowsデスクトップアプリ開発可能、exeファイルを生成、マイクロサービス対応など
マイクロソフトはオープンソースで開発している.NETフレームワークの最新版「.NET Core 3.0」正式版のリリースを、オンラインイベント「.NET Conf 2019」で発表しました。 マイクロソフトが提供するおもなフレームワークには、Windows向けの「.NET Framework」、当初はおもにサーバアプリケーション向けとして登場したオープンソースの「.NET Core」、そしてモバイル向けの「Xamarin」の3つに大別できます。 今回リリースされた「.NET Core 3.0」では、これまで可能だったLinuxやWindows Serverのサーバーアプリケーションの開発に加えて、Windowsデスクトップアプリケーションの開発が可能になったことが最大の特徴です。 以下、.NET Conf 2019で紹介された.NET Core 3.0の特徴を中心に紹介しましょう。 .NE
みなさんこんにちは、電通国際情報サービス（ISID）Xイノベーション本部ソフトウェアデザインセンターの佐藤太一です。 少し前になりますが4/23に、私はGo Conference 2022 SpringにおいてGo で RDB に SQL でアクセスするためのライブラリ Kra の紹介というタイトルで登壇しました。 登壇時の資料はこちらです。 このエントリでは、スライドを作成する際に私が考えていることや、情報を整理する方法について説明します。 伝えたいメッセージを作りこむ アイディア出し 初期のアイディア出し例 アイディアの統合 アイディアの統合例 メッセージの絞り込み メッセージの例 今回のメッセージ 伝えたい情報を構造化する 構造のテンプレート 論理の順序を整理する まとめ 伝えたいメッセージを作りこむ 私が技術系のイベントに登壇する際に最も重視しているのがメッセージの作りこみです。
POSAでの定義 レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。 コンテキスト ソースコードの変更がシステム全体に波及させたくない。それが1つのコンポーネントに閉じられ、他に影響を与えないようにすべきだ。 インタフェースは安定している。標準化団体によって規定されている場合もある。 システムの一部は交換可能である。コンポーネントはシステムの他の部分に影響を与えることなく、実装を入れ替えることができる。 現在設計しているシステムと同様の下位レイヤの課題をもつ他のシステムを、将来構築することがあるかもしれない。 理解のしやすさと保守性のために同じ責務はグルーピングしておきた
分散データシステム入門の決定版『データ指向アプリケーションデザイン』をたった30分で学んでみた #DataEngineeringStudy | DevelopersIO
基調講演「30分でわかるデータ指向アプリケーションデザイン」 ・ スピーカー 斉藤 太郎氏 Twitter：@taroleo / Github：@xerial Principal Software Engineer , Treasure Data 東京大学理学部情報科学科卒。情報理工学 Ph.D。データベース、大規模ゲノムデータ処理の研究に従事。その後、スタートアップであるTreasure Dataに加わり、アメリカ、シリコンバレーを拠点に活動中。日本データベース学会上林奨励賞受賞。OSSを中心にプログラミングやデータ処理を簡単にするためのプロダクトを作成している。 「30分でわかるデータ指向アプリケーションデザイン」最新の論文にも触れながら、分散データシステムの世界の魅力を伝えていきます。後半、@tagomoris https://t.co/TQ2TnsFIOT… — Taro L.
Rustでリレーショナルデータベースを自作したときの成果と反省と学び - Yoshisaurのメモ
はじめに この記事では、個人プロジェクトとしてRust言語でリレーショナルデータベースを開発した経験（もう五ヶ月も前...）について、その成果と反省、得た学びを共有します。 DBMSを自作した理由 自分がDBMSの自作に着手したのは、『Designing Data-Intensive Applications』という本の内容を深く理解するためでした。 この本は、データシステムの設計と運用において最も大切な「信頼性」、「拡張性」、「保守性」を保証する方法論を、豊富な文献を引用しつつ、理論と実践の橋渡しを巧みに行いながら、丁寧に説明している名著です。読んだことがない人は速攻購入してくだい。本当にいい本です。 この本は、データベースの内部構造に関する話も豊富に含まれていたので、「データベース自作してみようか...」という気持ちになりました。 Rustを採用した理由 データベースの実装のついでに、
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
マイクロサービスに次に来るかもしれない言葉について - arclamp
ソフトウェア設計の Why & What & How | Wantedly Engineer Blog
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
ソフトウェア設計原則は変更容易性に通ず - Shin x Blog
モダンなソフトウェア設計の書籍 - kawasima
モダンBFFを活用した既存APIサーバーの再構築 - クックパッド開発者ブログ
なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
DDD(ドメイン駆動設計)、理念に大賛成、実装に大反対。
ドメイン駆動設計は何を解決する手法なのか - stmn tech blog
エストニアは本当に「電子国家」なのか--現地に移住した日本の若者がみた実情
AWS WAF について最初から知りたかったこと8選 - 電通総研 テックブログ
コードは2回書きたい - Mitsuyuki.Shiiba
RESTful API との比較で GraphQL API を作ることの難しさ｜qsona
マイクロサービスにクリーンアーキテクチャを採用する上で考えたこと | メルカリエンジニアリング
技術系イベント登壇における資料作成のコツ - 電通総研 テックブログ
レイヤードアーキテクチャ - kawasima