Modular Monolith(モジュラーモノリス)についてまとめる
モジュラーモノリスについて 目次 モジュラーモノリスとは メリット デメリット・課題 採用例・実装例 必要・向いているケース 不必要・向いていないケース そもそもマイクロサービス メリット デメリット・課題 マイクロサービスを選択する理由 マイクロサービスを採用すべきでない時 とりあえずまとめ そもそもモノリス デメリット・課題 モノリスの種類 参考 モジュラーモノリスとは モノリスからマイクロサービスへでは単一プロセスのモノリスのサブセットと紹介 独立して作業が可能なモジュールで構成され、デプロイ時に結合 モノリスアプリケーション内で、ドメインモデル等を単位としてモジュールに分解し、モノリスのように1つのデプロイパイプラインだけを持ちつつも、マイクロサービスのようにシステムのモジュール化・独立性を両立 マイクロサービスアーキテクチャの場合OrderサービスやPaymentサービス等が独立
OWASP、Webアプリの重大なリスクのトップ10「OWASP Top Ten 2021」を公開
Webアプリケーションセキュリティなどの改善活動を行う非営利団体「The Open Web Application Security Project」（OWASP）は2021年9月24日（米国時間）、Webアプリケーションの重大なセキュリティリスクのトップ10を選び、解説するドキュメント「OWASP Top Ten」の最新版「OWASP Top Ten 2021」を公開した。 OWASP Top Tenの更新は、前のバージョンである「OWASP Top Ten 2017」を公開した2017年11月以来3年10カ月ぶり。OWASP Top Ten 2021は英語版がWebで公開されており、ダウンロード可能なPDFとインフォグラフィックスもある。日本語を含む他の言語への翻訳も進んでいる。 OWASP Top TenはWebアプリケーションセキュリティに関する開発者向けの啓発ドキュメントであり、
技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
経営のアジリティを支えるDevOpsと組織
2015/07/29 Developers Summit 2015 Summerでの、志田の講演資料になりますRead less
RDRA２.０についてまとめみた（前編） - Qiita
はじめに RDRA2.0を勉強しようと思った理由 ドメイン駆動設計を勉強しているなかで、BIGLOBEさんの取り組みについて書かれた記事の中に、RDRA2.0という設計手法があるということが書かれていました。 なにやらドメイン駆動設計とRDRA2.0という設計手法は親和性が良いとのことなので、RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法を参考に勉強しました！ 目次 RDRA2.0に取り組むモチベーションとは RDRA2.0とは？ 各レイヤーの概要説明 対象読者 RDRA2.0について知らない人。 要件定義工程で困った経験がある人。 RDRA2.0に取り組むモチベーションとは 設計について抱えている課題 低品質の要件定義資料 要件定義設計書は、機能一覧やユースケース一覧などの大量の設計書を作成する必要がある。そのうえ、大量の設計書全体の整合性を担保しなくてはな
Microservices分割大全 - kawasima
Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ
なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明の難しいものです。 拙著においては、ロナルド・コースの取引コスト理論をベースに、社内取引においても取引コストが存在し、その取引コストがソフトウェアの構造をも変えていくという説明を行いました。 本記事は、さらに踏み込んで、組織やビジネスに働く力学と、システムで
システム保守契約のサンプルと留意点 - 弁護士法人クラフトマン IT・技術・特許・商標に強い法律事務所(東京・横浜)
システム保守契約とは システム開発が終了すると、多くの場合、開発したシステムの運用・保守について、ベンダ（受注者）とユーザ（発注者）で契約がなされます。 また、システム開発契約とは関係なく、システムの保守について委託契約がなされることもあります。 本ページでは、システムの保守契約・ソフトウェア保守契約（メンテナンス契約）を作成・締結する際の留意点についてご説明します。 システム保守契約作成・検討における留意点 システム保守契約と収入印紙 まず、システム保守契約に収入印紙の貼付は必要でしょうか。結論的にはその内容次第ということになります。 例えば、保守の内容に、システムのソフトウェアの不具合の修正や補修作業が含まれる場合には、これは「仕事の完成を約する請負契約」とされることが多いと解釈されます。 それで、この場合、単発的なものなら請負に関する文書（２号文書）に該当するとされ、契約金額に応じた
現場で役立つシステム設計の原則メモ - Qiita
※この記事は著者の増田さんの了解の上で限定公開させて頂いております。 https://twitter.com/masuda220/status/1215122054795522049?s=20 オブジェクト指向、設計がなぜ必要か = ソフトウェア全体の整理整頓をするため 第1章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎている ちょっとずつゴミコードが追加されていった結果 重複しているコードをutil神クラスに押し込むと、あらゆる関心事が集中してしまう 変更に強いプログラムの書き方 メソッドは短く、クラスは小さく 略語は使わない 意味のまとまりで空行をうまく使う 説明用のローカル変数の導入（変更の影響範囲を局所化） 1つの変数に代入を繰り返す破壊的代入を避ける 意味のあるコードのまとまり（段落）を「メソッド
ビルの来客システムと Slack を連携させたら便利すぎてヤバい - SmartHR Tech Blog
こんにちは、コーポレートエンジニアの yamashu (@yamashush) です。 本記事では、ビルの来客システムと Slack を連携させてみた話を書いていきたいと思います。 なにが課題だったか 弊社は2019年4月に六本木にオフィスを移転しました。 SmartHR 新オフィスの行き方 移転前にいたビルと比較して建物規模が大きくなり、1階にはフラッパーゲートが設置されています。ゲストの方の入館には、事前にお知らせしたワンタイムコードで入館証を発行していただくようになりました。 ワンタイムコードはビルから提供される 専用の Web システムで発行することになるのですが、これがなかなか 煩雑な作業 なのです。 サイトを開いて、ログイン等の前動作が必要 申請時の必須入力項目が10個くらいある 申請完了後にその場でワンタイムコードが確認できない（2〜3分後にメールで申請結果が届く） 移転前に
autovacuumのチューニング要素について考えてみる - Qiita
この記事はPostgreSQLアドベントカレンダーの21日目の記事です。 昨日は @kasa_zip さんの PostgreSQLのバックトレースレポート機能 というPostgreSQLの新機能についての記事でした。 サーバログにバックトレースを残せる機能がPG13で追加されるかもということです。たしかにレアケースを踏んでSEGVになったときは再現が難しいのでこういう機能があると良さそうですね。（まだ、試作段階で用途は少なそうということらしいですが。） はじめに 突然ですが、autovacuumってちゃんとチューニングしていますか？ 正直自分はあまり意識したことがなかったですが、最近、お仕事の中で設定値について考える機会が多かったので、せっかくなので整理してみようと思い、アドベントカレンダーのテーマとして選びました。 裏付けのための検証をもとに まとめ を最後に書いていますので、お忙しいか
プラットフォームの上でものを作るということ
プラットフォームの上でものを作るということ Amazon EKS Advent Calendar 2019 の最終日です. みなさまご存知の通り、AWS には Amazon ECS と Amazon EKS という2つのコンテナオーケストレーションに関するサービスがあります. ECS は2014年に発表された AWS ネイティブなコンテナオーケストレータ、EKS は OSS のコンテナオーケストレータである Kubernetes をマネージドな形で提供するサービスで、2017年に発表されました. 今日はこの Amazon ECS と Amazon EKS という2つのサービスについての話を書こうと思います. // 読んでくださっているみなさまをミスリードしないための DISCLAIMER 本記事の著者は AWS に勤めています. また、この記事には僕個人の意見や想いも強くこもっています.
codic - デベロッパーのためのネーミング辞書
codicは、プログラマーのためのネーミング辞書です。新しいcodicでは、翻訳エンジンを搭載しネーミングをジェネレートできるようになりました。
なぜシステム会社の見積りが「ボッタクリ」に見えるのかを、きちんと説明する。
どうもしんざきです。曲がりくねったSQLを読んで、モニターを威嚇しつつ不要なjoinを削除しまくる仕事で主に生計を立てています。 こんなまとめを読みました。 某大手企業の本社を辞めるという人『古い会社は社内の体制も古い。癒着してるシステム会社も全然ダメでテキストの左揃えを右揃えに変えるだけで300万取られる』（現在は非公開） ワイの妹ト○タの本社やめて転職するらしいんだけど、「古い会社は社内の体制も古くてダメ。癒着してるシステム会社も全然ダメで、テキストの左揃えを右揃えに変えるだけで300万取られる上、バグ（仕様）だらけで仕事にならない」って言ってたの印象深い。 これ、もともとの話の情報量が全然なくって、何のシステムの話かも分からなければシステムの規模も分からないので、300万が高いのか安いのか妥当なのか、というのは勿論なんとも言えないです。 もしかするとこれはぼったくり案件なのかもしれま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
