Amazon Web Services ブログ AWS Lambdaによる進化的アーキテクチャの構築 この投稿は、メディアとエンターテインメントのプリンシパルソリューションアーキテクトであるLuca Mezzaliraによって書かれました。 俊敏性により、必要に応じてワークロードを迅速に進化させ、新機能を追加したり、新しいインフラストラクチャを導入したりできます。コードベースでアジリティを実現するための主な特徴は、疎結合コンポーネントと強力なカプセル化です。 疎結合は、テストカバレッジを改善し、一貫したリファクタリングを作成するのに役立ちます。カプセル化を使用すると、実装ロジックを明らかにすることなく、サービスとのやり取りに必要なものだけを公開できます。 進化的なアーキテクチャは、設計の俊敏性を実現するのに役立ちます。「進化的アーキテクチャの構築」という本の中で、このアーキテクチャは「複数
こんにちは。宿泊事業本部の宇都宮です。この記事では、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, 依存性の注入)とは、あるオブジェクトが依存しているオブジェクトを自ら用意するのではなく、外部から渡してもらう（外部から注入する）というデザインパターンです。 例として、以下のように、監督の名前を渡すとその監督の映画を全てリストにし
[Go] レイヤードアーキテクチャの階層構造を守らないimportを警告するlinterを作った - My External Storage
Goでクリーンアーキテクチャ等のレイヤードアーキテクチャを実装するための静的解析ツールを作った。 「webhandlerパッケージからusecaseパッケージを使わずに直接domainパッケージを使わないで！」というような、やってほしくないimportをエラーにできる。 https://github.com/budougumi0617/layer TL;DR クリーンアーキテクチャなどのレイヤードアーキテクチャでは、利用できるパッケージに制限がある レイヤー間の依存関係は一方向のみ 同じ層、あるいは1つ下の層のパッケージしか利用してはいけない https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html Goは循環importができないので、自然に単方向依存は満たしやすい しかし、層を飛び越して、2
![[Go] レイヤードアーキテクチャの階層構造を守らないimportを警告するlinterを作った - My External Storage](https://cdn-ak-scissors.b.st-hatena.com/image/square/f3ca5145f819bb37539bafba90f1c2353dbe1f00/height=288;version=1;width=512/https%3A%2F%2Fbudougumi0617.github.io%2Flogos%2FGo-Logo_Aqua.png){kind=logo}
【全2回】AWS Lambda x FastAPIによるPythonモダンAPI開発のすゝめ 2 - RAKSUL TechBlog
はじめに 対象読者 あまり説明しないこと 前提とするバージョン 参考となるレポジトリ 3. アーキテキチャ及びディレクトリ構造 オニオンアーキテクチャを採用 オニオンアーキテクチャとは 誕生の背景 依存関係逆転の原則の活用 採用理由 参考になった記事 ディレクトリ構造 全体の構成 api schema apiとusecaseの間のデータ構造を提供する役割 schemaはパスオペレーション関数のリクエストとレスポンスの構造を提供する役割 usecase domain infrastructure core container_config exception 参考にしたもの まとめ はじめに ラクスルグループのノバセルで新卒2年目のエンジニアをしています田村(tamtam)です。 第1回では、AWS Lambda x FastAPIによるPythonモダンAPI開発を実現する上で役立つであろ
GradleのマルチプロジェクトによるKotlin、Spring Bootでのオニオンアーキテクチャの実現 - タケハタのブログ
4月に発売した書籍「Kotlin サーバーサイドプログラミング実践開発」なのですが、この中で途中まで作っていてボツネタにした内容がありました。 gihyo.jp それが「Gradleのマルチプロジェクトでオニオンアーキテクチャを実現する」というものです。 第2部で作成していたbook-managerというアプリケーションは、もともとこれを使って作成していましたが、途中でやめて現在の形になりました。 github.com ボツネタにした理由としては、一回実践で導入してみていくつか微妙な点があったことと、紙面上の説明が複雑になるのでベーシックな内容としては外していいかなと思ったためです。 ただせっかく途中まで作っていたので、試して微妙と感じた点も含めて、今回紹介したいと思います。 サンプルとしてこのbook-managerの内容をマルチプロジェクト化したアプリケーションを使い、オニオンアーキテ
はじめに RustでWebアプリケーションのGraphQLバックエンドを実装してみました。その中で、できるだけClean Architectureに沿うように実装してみたので、得られた知見を公開してみたいと思います。 資料に基づきできるだけ正確な記述を目指していますが、誤りもあるかもしれません。また実装から少し時間を空けて執筆しているので、忘れている部分も多く不正確なことが書いてあるかもしれません。 Clean Architectureとは 以下のブログでRobert C. Martin（通称Uncle Bob）によって提唱されたアーキテクチャです。 その後本人により書籍も出版されました。日本語にも翻訳されています。 歴史について簡単に 多層アーキテクチャ (Multitier architecture) というものはかなり昔から考えられていたようです。初出についてはよくわからないのですが
依存関係逆転の原則に苦しんだ方々、いかがお過ごしでしょうか。 今回はアプリ設計の話です。 アプリ設計におけるクリーンアーキテクチャについて少し語り、調べていくうえで誤解していた部分や理解しにくかった部分を語ったうえで、オニオンアーキテクチャとクリーンアーキテクチャというよく似た二種類のアーキテクチャの説明をしていく、という流れとなっています。 言葉の定義について ここではアーキテクチャにおけるインターフェイスとプログラミング言語におけるインターフェイスを区別するために、プログラミング言語におけるインターフェイスを抽象型と表記します。 それぞれの言語において、抽象型は以下のような言語機能で実現されています[1]。 Java, C#などにおける抽象クラス abstract class Java, C#, Golangなどにおけるインターフェイス interface rustにおけるトレイト t
Python で学ぶ実践的なドメイン駆動設計とレイヤードアーキテクチャ / DDD and Onion Architecture in Python
2021年10月に開催された PyCon JP 2021 Day 1 の登壇資料です。 CfP より抜粋 ドメイン駆動設計（DDD）やクリーンアーキテクチャといった話題は定期的に盛り上がりを見せますが、Pythonにおける実践的な解説はいまだ多くありません。このセッションでは、分かりやすく具体的なコード例を織り交ぜながら、これらについて解説を行います。聴衆は、他の言語の仕様や実例と比較したうえで、フラットな目線で Python で DDD に取り組むことの良い点と課題点を見つけることができるでしょう。
概要 オニオンアーキテクチャはJeffrey Palermo氏により考案されたアーキテクチャパターンである。伝統的な階層化アーキテクチャとオブジェクト指向の考え方を踏襲しつつ、これまでよりも保守性、テスト容易性、依存性の点で優れたアプリケーションを構築することを目的としている。本記事ではこのオニオンアーキテクチャとは何かについてPalermo氏の記事を参考にして考察する。 前提となる知識 オニオンアーキテクチャを理解する上で前提となるいくつかの知識を挙げる。 オブジェクト指向 オニオンアーキテクチャはオブジェクト指向を前提としたアーキテクチャである。 階層化アーキテクチャ オニオンアーキテクチャは多層アーキテクチャを利用している。 依存性逆転の原則 オニオンアーキテクチャでは依存性逆転の原則がオブジェクトのモデリングに利用されている。 ドメイン駆動設計 Entity, Repository
TL;DR 巨大なモノレポはパッケージ間の依存関係に気を付けないと、変更が思わぬ所に波及して保守が大変だって？ DeepFlow 株式会社製ツール guardian を使って、Haskell モノレポのパッケージ間の依存関係が抽象化や意味論的な境界を侵犯していないかチェックしよう！ この度 OSS 化したので、巨大 Haskell モノレポの依存関係管理に困っている皆さんは是非試してみてください。 GitHub Action もあるよ。 はじめに - 巨大モノレポを保守する悲しみ 大量のパッケージから成るモノレポ[1]を管理するのが大変だというのは、あらゆる言語で共通の悩みであろうと思われる[2]。 こうしたモノレポというのは、「CIで全部ビルドできるようにしておく」というだけでは不十分で、ある箇所への変更が必要以上の部分のリビルドを惹き起こさないようにしないと、開発サイクルが全然回らずに
はじめに こんにちは、初めまして、iOSアプリエンジニアのtasaiです。この記事は リクルートライフスタイル Advent Calendar 2019 19日目の記事です。私は入社したばかりなので業務で使っている技術についてではなく、業務で採用してみたいiOSアプリのアーキテクチャと技術についてご紹介します。 前提 業務でMVVMでのアプリリニューアルやVIPERでのリアーキテクチャをしてきた経験をもとに、クロスプラットフォーム技術の採用を視野に入れて検討した内容となります。 解決したい課題 モバイルアプリの開発において継続的に改善を行うようなプロダクトでは、以下のような課題があるのは珍しいことではないかと思います。 長年の運用で溜まっていた技術的負債 ユニットテスト/UIテストコードが書きづらい責務分割 そもそも設計方針が決まっていなかったり、複数のアーキテクチャを抱えたりしている A
Software Architecture - DDD と アーキテクチャ にまつわるエトセトラ - Qiita
要約 / inb4 tl;dr DDD（ドメイン駆動設計）について調べ始めたら、解説記事でお腹いっぱいになった。 更に、一緒に語られるアーキテクチャも整理したい欲が出てきた。 Layered Architecture Layered Architecture with DIP (Dependency inversion principle) Hexagonal Architecture Onion Architecture Clean Architecture こういった経緯で、元になった書籍や記事をまとめてみた。 ちょっとしたまとめも書いた はじめに 『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』 を読んで DDD入門をしてみて、ボトムアップで作り上げるときの アーキテクチャ に興味が湧き、今後、調べていくに当たって最初に見るべきであろう情報をまとめてみました。
はじめにはじめまして！21年新卒としてSHIFT DAAE(ダーエ)開発グループに所属されました田中です。 DAAEでの新卒研修終了後、初めてアサインされたプロジェクトにてサーバーサイドKotlinを使ったDDD開発に取り組むことになりました。当初DDD開発未経験だった頃からそのプロジェクトに携わり早１年…、DDD開発の経験談やその魅力を少しでも共有できればと思いここにまとめます。 ｜DDD（ドメイン駆動設計）とはドメイン駆動設計の著者エリック・エヴァンスさんは、DDDは以下の４つから成り立つと言っています。 ・Focus on the core complexity and opportunity in the domain ドメイン(*1)の中核となる複雑さと機会にフォーカスする ・Explore models in a collaboration of domain experts
Next.js はSSR対応したReactを使ったUniversal JavaScriptフレームワークで、Vueを使っている Nuxt.js とよく比較されています。 セットアップがとにかく簡単で、TypeScript対応も非常に簡単です。(tsconfig.json の空ファイルを置いておくと自動的に中身を作ってくれます！) 今回とあるSPAを作成するにあたって Next.js を採用したため、そのとき考えたアーキテクチャー設計を書き残したいと思います。 ディレクトリ構成とクラス設計 ディレクトリ構成はクラス設計にも反映される重要な部分になります。 近年自分が好んでいるクラス設計は「Onion Architecture + Clean Architecture + Re-Ducks Pattern」です。 (React Nativeでもこの構成でアプリケーションを作成しています) フロ
DDDの一般的なアーキテクチャをまとめてみた
はじめに 久しぶりの投稿ですが、仕事の中でDDDに関連したアーキテクチャを整理する機会があったので、改めて知識の整理のためにまとめておきたいと思います。 一般的なWebアプリケーションのアーキテクチャ(3層アーキテクチャ) 矢印の方向に依存していきます。 一般にこの依存関係を持ってwebアプリケーションは作られますが、ビジネスロジック層が肥大化する傾向が多いです。 それぞれの層を言語化すると以下のようになります。 プレゼンテーション層 = クライアントとの入出力をする層 ビジネスロジック層 = ビジネスロジックの実現をする層 データアクセス層 = データベースとの入出力をする層 問題点 その中でビジネスロジック層は、そもそもビジネスロジックが複雑になりがちなため、うまく設計ができずに、メンテナンス性の悪い、所謂神クラスの氾濫(xxxService、xxxManager)が起こりがちです。
Introduction Writing maintainable code should always be taken into consideration as it is as important as scalability, resilience, and other infrastructure aspects when you have your application running in production. There are many architectural principles that a maintainable code implements, and the source code for the project structure that we will go through in this article is available in a G
Hexagonal Architecture とは Clean Architectureなどのような、Onion Architectureの一種です。 最近だと、Netflixで採用されています。 基本的には、AdapterとCoreの2層のみで、UIやAPI Interfaceなどが、Adapterでそれ以外のApplicationの処理をCoreが担います。 Hexagonal（六角形）というのはAdapterでIN/OUTするポート（Web API、ファイル入出力など）が6種類別々に分けられているところから由来しているらしいですが、現在だといろんなIN/OUTの方法があるので、概略図とか見ても6つで収まってないですｗ 実装コンセプト この先、読み進めていってClean Archtectureと何が違うのと思う方もいるかと... 正しいと思います！！ ごりごり細かく作っていくとClea
How to get started DDD & Onion-Architecture in Python web application
I've also written a git of it on README. But in some ways, DDD is too difficult for us to understand; I would like to explain this architecture. Motivation My day job is to develop apps for smartphones using Flutter. In this development, I've adopted DDD with Onion architecture. This approach has worked well so far. On the other hand, the requirements of a native application are more complex than
ソフトウェアアーキテクチャには、依存関係のデザインという側面がある。その目的は多くの場合において、ソフトウェアの振る舞いに対する変更容易性を高めることではないだろうか。 ソフトウェアプロダクトは、そのライフサイクルを通して、繰り返し変更し続けられていく宿命にある。それがユーザーや顧客の要求であり、彼らの価値につながるからだ。そしてその提供には迅速さも求められる。依存関係のデザインは、これを実現するために組み込まれたソフトウェアの構造なのだ。 アーキテクトの悩みのひとつは、このような目的に基づいて自らがデザインしたソフトウェアの構造が、儚く崩れ去っていくことだ。アーキテクチャとは所詮はルールでしかない。開発チームが厳密にルールを守らない限り、望ましい構造を構築・維持することはできない。アーキテクチャは脆いのだ。それこそが技術的負債の一因でもある。 無償のJavaライブラリとして提供されている
爆速開発を目指して NewsDigest を Flutter にリプレイスします JX通信社 Engineering Manager の @jazzsasori です。 最近アークナイツというソシャゲに課金してしまいましたが妻には内緒にしています。 弊社は NewsDigest という無料ニュースアプリを運営しています。 NewsDigest は記者が業務で愛用するほど、その圧倒的スピードに強みがある速報アプリです。また、一般的なニュース分野での速報に加えて、報道はされにくいが個人にとって価値の高い情報も to B 向けのリスク情報SaaS である FASTALERT と連携して即時に伝える、社会派ニュースアプリです。 現在 (2021/11) 500万ダウンロードを突破しており、今後もさらにユーザーを伸ばそうとしています。 なぜリプレイスを行うのか サービスとしては 2015年 にストア
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
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
はじめに この記事では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が受容され得るかどう
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
Developing evolutionary architecture with AWS Lambda | Amazon Web Services
AWS Compute Blog Developing evolutionary architecture with AWS Lambda This post was written by Luca Mezzalira, Principal Solutions Architect, Media and Entertainment. Agility enables you to evolve a workload quickly, adding new features, or introducing new infrastructure as required. The key characteristics for achieving agility in a code base are loosely coupled components and strong encapsulatio
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Lambdaによる進化的アーキテクチャの構築 | Amazon Web Services
GoのDIライブラリgoogle/wireの使い方 - 一休.com Developers Blog
RustでClean Architectureを実装してみる
クリーンアーキわからんかった人のためのオニオンアーキテクチャ
オニオンアーキテクチャとは何か - Qiita
Guardian で巨大 Haskell レポジトリの依存関係を正気に保つ
業務で採用してみたいiOSアプリのアーキテクチャと技術
初めて現場でDDD（ドメイン駆動設計）を実践してみた｜SHIFT Group 技術ブログ
Next.jsにおけるアーキテクチャー設計を考える
Clean architecture with TypeScript: DDD, Onion
GoではじめるHexagonal Architecture - Qiita
ArchUnitでアーキテクチャをテストする - mtx2s’s blog
爆速開発を目指して NewsDigest を Flutter にリプレイスします - JX通信社エンジニアブログ
Clean Architecture For React
Awesome Software Architecture
Vertical Slice Architectureについて
DDD and Clean Architecture — part 1