Aws Dev Day2021 「ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキル」参考資料(松岡パート)

こんにちは。バックエンドエンジニアの西尾です。 スペースマーケットではAPIサイドは主にRailsを利用していますが、最近は一部サービスでNode.js+Typescriptを使い始めました。 個人的にはまだ触れていなかった領域であったのでお勉強がてら簡単なコードを書いてみたいと思っていました。 また、Node.jsの他にもう一つ最近気になり始めていたものにClean Architectureという設計思想があり、Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでいます。 本の概要は、アプリケーションが成長するに従い徐々に改修コストが上がってしまう、これを防ぐためにはうまい方法、つまり良い設計を知っている方法があるという導入から始まり、設計の歴史、原則とそれを実現するための１手段としてClean Architectureという設計思想について語られています。

こんにちは、クラウドワークスの新規事業のエンジニアとして仕事をしている高梨です！ 最近、「実践ドメイン駆動設計」という本を読みました！ 500ページ近くもある技術書で、なかなか量は多かったのですが、DDDがどんなものなのか一通り大枠を掴めた気がします。 ただ読み終わった後にこんな疑念や不安をいだきました。 「たしかにかなり面白そうだけど、実際にやるとどれだけ工数かかるんだろう...？」 「設計の話は全然出てこなかったけど、DDDで作るとなるといったい何から始めればいいんだ？」 「戦術についての知識はついたけど、実際に書こうとしたらできなそうだな...」 そこで、そういった疑念や不安を解決するために、実際にDDDでサンプルプロダクトを作ってみようと思ったわけです。 実際に作ってみるのが、結局一番理解が進みますしね。 今回は、そのプロダクトがリリースされるまでの過程や感想を、作成した設計書やソ

要約 / inb4 tl;dr DDD（ドメイン駆動設計）について調べ始めたら、解説記事でお腹いっぱいになった。 更に、一緒に語られるアーキテクチャも整理したい欲が出てきた。 Layered Architecture Layered Architecture with DIP (Dependency inversion principle) Hexagonal Architecture Onion Architecture Clean Architecture こういった経緯で、元になった書籍や記事をまとめてみた。 ちょっとしたまとめも書いた はじめに 『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』 を読んで DDD入門をしてみて、ボトムアップで作り上げるときの アーキテクチャ に興味が湧き、今後、調べていくに当たって最初に見るべきであろう情報をまとめてみました。

Kei Sugimoto, “Two Domain Models - An Implication of DDD”, PHP Mentors, (December 20, 2015)  ドメイン駆動設計（Domain-Driven Design: DDD）は、オブジェクト指向、デザインパターン、リファクタリングなど、ソフトウェア設計分野における幅広い知的遺産と交差します。それゆえ、ドメイン駆動設計は、ドメイン指向のアプリケーションソフトウェア開発に馴染むような仕方でこれらの知識資産を統合したものと見ることができます。 こうした見方は妥当でかつ生産的でもありますが、DDDの業績に対しては別の見方もあり得ます。それがこの短い論考のテーマです。 この文脈において、DDDは、「ソフトウェア設計」から、私たちが特別な思い入れを込めて「情報設計」と呼ぶものへの静かな出発として考えることができるかもし

この記事は次の記事の続編に近い内容となっています。 もし可能であればこちらの記事を読み進める前に、次の記事をご覧いただくとより内容がわかりやすいでしょう。 Laravelで実践クリーンアーキテクチャ: https://qiita.com/nrslib/items/aa49d10dd2bcb3110f22 はじめに 皆さんこんな図をご存知でしょうか。 The Clean Architecture: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html これはクリーンアーキテクチャというアイデアを表した図です。 同心円が特徴的な図ですね。 この同心円は、最も重要なビジネスロジックを中心に見据えることで外界の変化から防衛、対応していこうというコンセプトを表しています。 より具体的にいえば、ビジネス

この記事を書くにあたって Laravel について色々サポートしてくれた皆さまに向けてお礼申し上げます。ありがとうございました。 本記事はクリーンアーキテクチャに対する理解を深めていただくために、「実践クリーンアーキテクチャ」の内容を Laravel で実装して解説するという内容になっています。 記事のゴールは「クリーンアーキテクチャに対する理解を深めてもらう」というものです。つまり、この実装の形は一例に過ぎません。 はじめに 皆さんクリーンアーキテクチャはご存知でしょうか。 そう、こんな図のアレです。 The Clean Architecture: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html クリーンアーキテクチャといえばこちらの象徴的な図をまずは思い浮かべるでしょう。 この図を

皆さんこんにちは。 虎の穴ラボのY.Fです。 今回は、いつものプログラミング系の記事とは趣向を変えて、株式会社オライリー・ジャパン様から発刊されている『ゼロトラストネットワーク』を読んだので、感想などをつらつら書いていきたいと思います。 www.oreilly.co.jp 読んだ動機 弊社ではオライリーの年間定期購読に申し込んでいます。なので、なんとオライリーの新刊が発売日には読み放題です！ これを活かさない手はないと発売前から気になっていた『ゼロトラストネットワーク』を読んでみた次第です。 (過去届いた書籍の一部はこちら) gramho.com gramho.com 目次 本書の目次は以下になります。 目次 はじめに 1章　ゼロトラストの基礎 1.1　ゼロトラストネットワークとは何か 1.2　境界モデルの進化 1.3　潜在的な脅威の進化 1.4　境界モデルの弱点 1.5　信用の在りか 1

タイトルにある「ネコのアプリ」というのは、僕が作ったものではありません。個人開発者が集まるslackグループ、運営者ギルド仲間の@ampersand_xyzさんが作ったものです（アプリの詳細はこちら）。 今回、そのアプリを世界最大級のプロダクト紹介サイトProduct Huntにて紹介したところ、その日のランキングで7位を獲得したというお話です。 対象読者 個人開発者や、スタートアップの方で、海外に自分の作ったプロダクトをローコストで広めたい方。 およそ1万字の記事なので、時間があるときにじっくり読んでいただければと。 なぜやったのか 自分が作ったアプリの海外展開を行うにあたって、海外の三大プラットフォームの動きを事前に体験してみたかったからです。 少しだけ自己紹介をすると、shinji といいまして、サイドプロジェクトとして個人開発で下記のようなサービスを運営しています。 日程調整アプリ

組み込みC言語ネットワークスタック開発者からGoバックエンドエンジニアにジョブチェンジしました。 最近はTypeScript, React(Hooks), GraphQL, SwiftUIに夢中。 Follow

概要 ドメイン駆動設計の有名な用語にエンティティというものがあります。 ほとんどドメイン駆動設計の代名詞のひとつと言っても過言でないほどの有名さを誇るこちらの用語ですが、なんとクリーンアーキテクチャにもまったく同じエンティティという用語が出てきます。 このエンティティという用語は名前こそ同じではありますが、実は完全に同じものを指しているわけではありません。 とはいえまったく違うものである、というわけでもありません。 要するにややこしい。 この記事はこのややこしい用語について、ドメイン駆動設計とクリーンアーキテクチャのそれぞれのエンティティが何を指していて、それがどのように異なっているのかについてを解説します。 それぞれのエンティティ そもそもエンティティとは何でしょうか。 英和辞典を引くとエンティティとは「存在［実在］物」といった意味が出てきます。 これはかなり抽象的な意味です。 つまり、

この記事について こちらの記事はクリーンアーキテクチャの Java 実装による解説記事です。 MVC フレームワークに組み込むために一部変更している部分もあります。 それをふまえてご覧ください。 講演内容が @IT さまに記事にしていただけました。 あわせてご参照ください。 https://www.atmarkit.co.jp/ait/articles/1907/08/news002.html クリーンアーキテクチャよりも軽量で無理なく導入しやすいアプリケーションアーキテクチャパターンを考案しました。 https://nrslib.com/adop/ スライド JJUG CCC 2019 Spring での発表資料です。 この発表をするにあたって記事を書くことにしました。 YouTube YouTube でこちらの解説を行いました。 その他解説もしています。もしよろしければチャンネル登録を

AmazonでMartin Kleppmann, 斉藤 太郎, 玉川 竜司のデータ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理。アマゾンならポイント還元本が多数。Martin Kleppmann… 手軽に扱えるデータの量や種類が増える一方、CPUの性能はムーアの法則通りには成長しなくなり、大規模データ処理では、多数のマシンを活用する分散処理が欠かせなくなってきました。クラウドの普及とともに多数のマシンを自ら調達せずとも分散システムを構築できるようにもなっています。 しかし驚くべきことに、今までこの分野に入門するための定番の書籍がありませんでした。分散処理にデータ処理が加わる融合分野である上、オープンソースプロジェクトの進化も速く、専門家同士でも共通の理解を構築するのが非常に難しかった分野です。この本を上手に使うと、既存のOSSプロジェクトの位置付けや、

イーロンマスク「Ethereumで何創ったらええの？」へのVitalikのリプが良スレ * グローバルにアクセス可能な金融システム(決済、保険など) * アイデンティティ(FBログイン→ETHで) * 登記 * DAOなど人類の新たな組織形態の実験 * 分散型のDNS * SNSスパム防止のためのクリプトエコノミクス など↓ https://t.co/ULzedanLvX — Obi / 大日方 祐介 (@obnty) April 30, 2019 思った以上に反響があったのと、ここでヴィタリクが提示しているアイディアはブロックチェーンで何か挑戦しようという日本人にはとても有益なのではと思い、もっとしっかり深掘りしてまとめてみます。 1. グローバルにアクセス可能な金融システム決済や価値保存といった基本的なものから、保険などより高度なものまで。いわゆる、ここ半年くらいでブロックチェーン界隈

Developers are expected to use increasingly powerful tools to deliver increasingly complex and innovative software. So, why do developer tools often feel like an IRS tax form?