アーキテクチャ選定の事例と学び ～モノリス、マイクロサービス、モジュラーモノリスの共生と最適化～ https://findy.connpass.com/event/344567/ 上記のイベントで発表した内容です。
2025/02/28(金) JSConf.jp おかわり Node学園46時限目
モノリスでは大変なので、マイクロサービスやモジュラーモノリスにして認知負荷を減らしたり、生産性の劣化に抗いたいという考え方がある。 モジュラーモノリスとは モジュラーモノリスについては、だいたい infoq.com のモノリスシリーズ（？）を読めば良いんじゃないか。 有名なのは Shopify のヤツ。 モノリスとマイクロサービスの中間にある、1 アプリケーションなんだけどモノリスでは無い、アプリ内でモジュール分けされているアーキテクチャのこと。app/ の直下に MVC を置くんじゃなくて、COMPONENTS (例えば billing)/app/ の下に MVC を置く、ようなイメージ。 モジュラーに移行するタイミング 僕の感覚だと、数百モデルは全然モノリスで扱えると思っている。少なくとも 300 models 程度でモジュラーにしていく必要はまったく感じない。 世の中で見つけたモデル
クリーンアーキテクチャなんてものはない(クリーンアーキテクチャーの読み方)
すでに何人かの人がクリーンアーキテクチャなんてないよ、って話はしていてイマサラだと思うんですが。 あえてブログの記事に残そうかなと思って書いてみます。 最近、改めてクリーンアーキテクチャ本を読んだり、原文を読んだり、 ここ数ヶ月ツイート色々な人のを観測したり社内で話したりしていて 考えがまとまってきたので、自分の言葉で整理してみたくなった。 「へー、クリーンアーキテクチャっていうソフトウェアアーキテクチャがあるんだー」という微妙な誤解？をちょっとでも減らす一助になればという感じです。あと、本の読み進め方のヒントにもなるかも 先に結論 クリーンアーキテクチャというのはアンクルボブの書いた本。 ソフトウェアアーキテクチャのことではない。 the クリーンアーキテクチャというブログ記事はただのソフトウェアアーキテクチャの例(そして本の一部分)だが、独り歩きしている クリーンアーキテクチャというソ
はじめに アプリケーションレイヤーでトランザクションを考慮した実装をどのようにすればいいのか悩んでいる人が多いことに気がつきました。オニオンアーキテクチャ等でアプリケーションコードを関心ごとのレイヤーに分離するときに、トランザクションを開始するためのDBとのコネクションの作成をどのレイヤーで実施するのか悩んでいる人が多いそうです。 本記事ではDDD+オニオンアーキテクチャ+Repositoryパターンを使う前提で、私がよく使うトランザクションを考慮した実装について説明しようと思います。 トランザクションを考慮した実装 私はトランザクションを開始するためのDBとのコネクションの作成はUsecase層で実施します。 私がよく書く実装ではDDDでいうEntityを定義します。そしてRepositoryではEntityのCRUDのみ行うように実装し、Repositoryをトランザクション境界にしま
この記事は、37signalsのプログラマーであるJorge ManrubiaさんのCode I likeというRailsの設計技法に関する連載記事の第五弾[1]を翻訳したものです。 ご本人の許諾をいただいて翻訳・公開しております。翻訳で至らない点などございましたらコメント頂けますと幸いです。 英語記事: Active Record, nice and blended 原文公開日: 2022/12/16 原著者: Jorge Manrubia Active Recordは、「永続化とドメインロジックをどのように分離するか？」 という従来の問題に対し次のような再提案をしています。「もし分離する必要がないとしたら？」 リレーショナルデータベースへのオブジェクトの永続化は複雑な問題です。20年前は、この問題は「プログラマーが気にしなくてもいいように永続化を抽象化する」という、究極の直交性[2]の
プレゼンテーションレイヤ、いわゆるフロントエンドがクライアントサイドで実装・実行されるアーキテクチャ (注 1) において、管理画面/管理機能をあとから追加する際にどのような実装パターンがあるのかを整理してみます。 注 1: Presentation Domain Separation の実践の中でも、物理的にプレゼンテーションロジックとドメインロジックを分離しているアーキテクチャです。 用語の整理 プレゼンテーションレイヤ 三層アーキテクチャにおける、システムの利用者へユーザインターフェイスを提供する層です。本記事では"フロントエンド"とほぼ同義で使います。 OSI 参照モデルの第六層ではないです。 バックエンド Web API とは プレゼンテーションを持たない Web API (HTTP プロトコルを用いてネットワーク越しに呼び出すアプリケーション) とします。 プレゼンテーションレ
一昨日くらいに 「DIP してもどうせ辛くなるよね」的なことを適当にツイートしたら引用 RT や RT 後言及やエアリプで言及された上に「こいつは設計を何も理解しとらん」みたいなことを言われた。「俺は本当に何も理解していないのか？」と不安になったので、自分の考えをちゃんと書いておこうと思った。先に自分の立場を言うと、なんたらアーキテクチャとか SOLID 原則は有用だし自分も使うが、それを厳守しようとは思っていないと言う立場だ。 DIP とはなんだったか DIP(依存性逆転の原則)は SOLID 原則の一つで、一言で言うと「抽象に依存させると依存関係が逆転する」といったものだ。何のことやらという風になるので例だけ挙げると、UserRepository と UserService があってこのように定義すると class UserRepository { get() { return dat
I’m Joel Spolsky, a software developer in New York City. More about me. Read the archives in dead-tree format! Many of these articles have been collected into four books, available at your favorite bookstore. It’s an excellent way to read the site in the bath, or throw it at your boss. Ready to level up? Stack Overflow Jobs is the job site that puts the needs of developers first. Whether you want
Software development is a young profession, and we are still learning the techniques and building the tools to do it effectively. I've been involved in this activity for over three decades and in the last two I've been writing on this website about patterns and practices that make it easier to build useful software. The site began as a place to put my own writing, but I also use it to publish arti
はじめにmicroCMSの大西です。microCMSには2022年の5月に入社しました。普段は開発本部長として組織的な業務、エンジニアのサポート、開発全体の大まかなタスクの方向性を決めといった業務を行なっています。 microCMSでは昨年中盤以降にWebフロントエンドの設計パターンを刷新しました。採用した設計パターンはクリーンアーキテクチャです。 2回に分けて大西と森茂（フロントエンドテックリード）がmicroCMSのWebフロントエンドの設計パターンについて紹介します。 前提としてmicroCMSのフロントエンドはReact、状態管理にはuseState/useContextを使用しています。APIのキャッシュにReact Query（TanStack Query）を使用しています。比較的素朴な設計になっています。 背景と課題microCMSはサービス開始から数年が経過しており、バック
Screaming ArchitectureEvolution of a React folder structure and why to group by features right away React folder structures have been debated for years due to React's unopinionated approach, leading developers to ask, "Where should I put my files? How should I organize my code?" I've researched the most popular approaches to organizing React projects: Grouping by file type like components, context
Building apps is too hard. Even skilled programmers who don’t specialize in app development struggle to build simple interactive tools. We think that a lot of what makes app development hard is managing state: reacting and propagating changes as the user takes actions. We’re exploring a new way to manage data in apps by storing all app state—including the state of the UI—in a single reactive datab
こんにちは、Sansanプロダクト開発部の清水です。 ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。 そもそもレイヤードアーキテクチャって何? 概要 一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。
Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
