『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』 - snoozer05's blog
翻訳を担当した書籍『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン）が3月8日に発売されます。本書は、2020年1月に出版されたMark Richards, Neal Ford著『Fundamentals of Software Architecture』（O'Reilly Media）を全訳したものです。 www.oreilly.co.jp ソフトウェアアーキテクチャとは、ソフトウェアシステムの成功に欠かせない重要な土台です。そのためソフトウェア開発者には、効果的なアーキテクチャを実現するスキルが求められます。本書は、そうした効果的なアーキテクチャを設計、構築、維持するアーキテクトになるために必要なスキルや知識を、現代的な視点から整理して包括的に解説する書籍です。 ソフトウェアアーキテクチャの定義から、アーキテクトの役割、モジュールや
マイクロサービスにおける非同期処理は何で実現させるか？ Callback地獄などを起こさないKotlin Coroutineのメリット
LINEが定期的に開催する、Kotlinをテーマにした技術者向けのミートアップ「LINE Developer Meetup for Kotlin」。ここで、開発3センターの岩谷氏が登壇。「LIVEBUY」の開発でKotlin Coroutineを利用した知見を紹介します。 自己紹介とセッションの概要 岩谷明氏：みなさんこんにちは。LINEの岩谷と申します。LINE Developers Meetup for Kotlinにご参加いただき、誠にありがとうございます。本日最初のセッションですが、「LINEでKotlinを活用してサービスを作っていく話」と題して、発表します。よろしくお願いいたします。 簡単に自己紹介します。私は2016年にLINE株式会社に入社しました。今までは「LINE LIVE」や「LINEノベル」などのiOSやAndroidのエンジニアをしていましたが、2019年から、本
最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita
TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一本槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる「イベントストーミング」がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で「結構日本でやられている取り組みとちがうなー」と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守（あるいは鹿鳴館精神）ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基本線となりつつある、、、のか？ まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも「ドメインイベント」として実装パタ
ソフトウェアアーキテクチャの基礎
ソフトウェアアーキテクチャとは、ソフトウェアシステムの成功に欠かせない重要な土台です。そのためソフトウェア開発者には、効果的なアーキテクチャを実現するスキルが求められます。本書は、そうした効果的なアーキテクチャを設計、構築、維持するアーキテクトになるために必要なスキルや知識を、現代的な視点から整理して包括的に解説する書籍です。 ソフトウェアアーキテクチャの定義から、アーキテクトの役割、モジュールや結合、アーキテクチャスタイルといったアーキテクチャ設計の基礎、チームやステークホルダーと効果的にコラボレーションしていくために必要なソフトスキルまで、さまざまなトピックについて実践的な例とともに説明します。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では、すでに修正
ブラウザで動くサービスを作るときの技術選定
はじめに 私の仕事は、新規サービスをまるっといい感じに開発するのを委託されることがほとんどです。最近はネイティブアプリを作ることよりもブラウザで動くWebサービスを開発することが多いのですが、案件の規模感や要求によって技術選定を少し変えるようにしています。「こういうときはこう」みたいに一概には言えないのですが、普段使う構成を紹介します。誰かの参考になれば幸いです。 2022/02/10 現在での内容です。 前提 開発を委託される場合の運用費をどうするの問題があります。クライアントにクレカ登録をしてもらうか、こちらで支払って毎月請求するかになります。僕は毎月やるのがめんどくさいのでできるだけ前者に倒している関係上、あまりいろいろなSaaSを組み合わせて作ることをなるべく避けています。 規模感によらず使っているもの 私の場合、以下が使えるとめちゃくちゃ効率よく開発できます。 GCP 好きだから
アプリケーションの設計にEIPの知識が役に立つよ！
非同期メッセージングを使ったインテグレーションパターン (EIP)は、クラス設計にも参考になるものが多い。 すぐに非同期メッセージングを使わないとしても、EIPは設計の参考情報として知っておきたい。
「コード書きました、あとはよろしく」では優れたソフトウェアは生まれない コンテナのスペシャリストが語る、運用性を損なう8つの実装例
今押さえておくべき知識をアップデートし、ノウハウを共有し、さらなるスキルアップを実現する場として開催されている、AWS で最も Developer に特化したカンファレンス「AWS Dev Day Online Japan」。ここでSr. Product Developer Advocate, Elastic Containersの原氏が登壇。続いて、運用性に優れたソフトウェアが重要な理由と、運用性を損なう8つの実装例について紹介します。前回はこちらから。 You build it, you run it 原トリ氏：（スライドの「You build it, you run it」を指して）この言葉、聞いたこと、見たことがある方がいるかもしれません。これは、2006年にACM（Association for Computing Machinery）という団体が、Amazon AWSのCTOで
状態、結合、複雑性、コード量の順に最適化する - valid,invalid
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
AWSでサーバーレス設計を考える時の手引き書 - Qiita
はじめに サーバーレスに触れて数年が立ちました。 そろそろ人にある程度説明ができるレベルの知識と経験が備わったような気もするので、年末なのでまとめてみました。 サーバーレス気になっているけれども、という人に少しでもためになればいいなーと思います。 サーバーレス基礎 皆さん、サーバーレス設計という話を聞いたことはあるでしょうか？ まずサーバーレスについて説明しますが、世の中にはたくさん解説記事があるのでそちらも適宜参照ください。 サーバーレスでも実際にはサーバーは存在する サーバーレスとは開発者がサーバーのことを意識しなくてもよい、ということ Function as a serviceに代表されるように、あるプログラムの実行環境を提供するが、プログラムの動作環境は開発者は意識する必要はない、というイメージ 恐らく、AWS Lambdaが一番理解しやすいと思います。 AWS Lambdaではプ
マイクロサービス化や大規模リファクタリングの手順を学ぶ - モノリスからマイクロサービスへを読んだ - $shibayu36->blog;
本当に最高の本でした。マイクロサービス化に取り組んでなかったとしても、規模が一定以上大きいプログラムのリファクタリング手法としても勉強になるので、みんな読みましょう！少なくともマイクロサービス化をしていきたいと思っていて、この本を読んでないならば、まずは一旦手を止めて関係する人全員でこの本を読んでから再度手を動かす、くらいでも良いレベルと感じました。 モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド 作者:Sam NewmanオライリージャパンAmazon この本を読んでいると、マイクロサービス化をしたいときは、必ず以下の手順でやっていくべきと感じました。 目的を明確にする 達成したいことは何か？事業が達成しようとしていることにあった一連の成果が目的でなければならない。これは、システムのエンドユーザーへのメリットを説明する方法で明確にできる その目的を達成するために、な
技術選定とアーキテクトの育成について - NRIネットコムBlog
こんにちは佐々木です。NRIネットコム Advent Calendar 2021 開催中です。しかし、内部で検討した結果、私は枠外になりました。ということで、Japan APN Ambassador Advent Calendar 2021として書かせていただきます。どちらも宜しくおねがいします。 今日のテーマは技術選定とアーキテクトの育成についてです。ITエンジニアの間には、定期的にどう技術選定するのかといった議論が出てきます。いろいろな観点があるとは思いますが、私が重要であると考えている所を簡単に述べてみます。 技術選定に銀の弾丸はない まず最初に言っておきたいのが、『技術選定に銀の弾丸はない』ということです。銀の弾丸とはIT業界でもよく利用される比喩で、英語で“silver bullet”とは「狼男を倒せる武器」が元々の意味です。それが転じて「困難を解決する決め手」という意味で使われ
サーバレス時代のマルチテナンシーを考える ~ Thinking about multi-tenancy in the serverless era ~ #cm_showcase | DevelopersIO
サーバレス時代のマルチテナンシーを考える ~ Thinking about multi-tenancy in the serverless era ~ #cm_showcase 京セラのロボティクスチームがマルチテナンシーをどのように考え取り組んできたか、またその過程でクラスメソッドがどのように支援してきたかをご紹介します こんにちはおんづか(@onzuka_muscle)です。 本記事ではMAD事業部として1年以上前から支援をさせていただいている京セラ様のセッションをレポートします！ セッション概要 サーバレス時代のマルチテナンシーを考える ~ Thinking about multi-tenancy in the serverless era ~ 昨今、DX 言葉に代表されるように、ビジネスをデジタライズし、サービサーとしてソフトウェアを提供するニーズが高まっています。 しかし、サービ
緩やかに死んでいくシステム / You won't be in the team forever
Talked at Cloud Native Lounge #2「クラウドネイティブなシステムの継続的改善と企業文化」. https://forkwell.connpass.com/event/215798/
kintoneマイクロサービス化検証プロジェクトのWebフロントエンドにおける技術選定 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームのsakitoです。 本記事ではkintoneをマイクロサービス化するためのPoCプロジェクトにおけるWebフロントエンドの技術選定について紹介します。 プロジェクト背景 本記事で扱うプロジェクトは「kintoneマイクロサービス化Proof of concept(PoC)プロジェクト」です。 現在サイボウズの主力製品であるkintoneは大きなモノリシックなアーキテクチャになっています。 モノリシックなサービスに関わる人数が増えるに伴って、意思決定や開発速度の低下が課題となってきています。 モノリシックなアーキテクチャや組織によって起こる課題を、マイクロサービスとして切り離して小さくすることで解決ができるのではないかと考えました。マイクロサービス化にあたって、まずはPoCとして一部の機能をマイクロサービス化するプロジェクトを発足し、kinton
GraphQL と Prisma から考える次のN年を見据えた技術選定 / Architecture decision for the next N years at StudySapuri
JSConf JP 2021 で登壇した資料です #jsconfjp #jsconfjp_b Links: [Active Recordから考える次の10年を見据えた技術選定](https://speakerdeck.com/yasaichi/architecture-decision-for-the-next-10-years-at-pixta) [GraphQL を活用したスキーマ駆動開発の実践](https://speakerdeck.com/qsona/schema-driven-development-with-graphql) [GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL - Speaker Deck](https://speakerdeck.com/qsona/architecture-pract
イミュータブルでゆこうに参加してきた - 天の月
modeling-how-to-learn.connpass.com 今日はこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。 会で話されていたこと イベント資料 イミュータブルデータモデルの極意～川島義隆さん～ 川島さんの問題意識～Division into cases～ Dataの場合分け EventとResourceの関係性 EventとResourceのサブタイプ Resource同士の関連付けをする際のコツ 記録として残すEvent, 残さないEvent ドメイン駆動設計とイミュータブルデータモデルの素敵な関係～増田亨さん～ イミュータブルについての厳格性 必ずイミュータブルにする際の設計パターン 増田さんがイミュータブルに拘る理由 ドメインイベントの観点から再考するソフトウェア設計～かとじゅんさん～ ドメインイベントとは ドメインイベントはなぜ有用か
プロジェクト内で完結するESLintのローカルルールを作りたい
はじめに ある日、クリーンアーキテクチャで定義した各レイヤーの依存関係が正しいかどうかを ESLint がチェックしてくれると楽だよねという話が出た(今のプロジェクトではこのような構成を取り入れております) ESLint に追加したいルールの要件を整理してみるとわざわざ plugin として公開するほど汎用的なものでもないと思い、プロジェクト内で完結する ESLint の独自ルールを作ってみたというお話 ゴール 下記に示すディレクトリ構成で以下の条件をチェックしたい domains配下のファイルはinfrastructures、adapters, usecases, view-modelsを import しない usecase配下のファイルはinfrastructures、adaptersを import しない view-models配下のファイルはinfrastructures、ad
アルパカ証券 技術ノート｜アルパカ証券の裏側 - はじめに
こんにちは。shirou(@r_rudi) と申します。アーキテクトという名の雑用係をしています。 Alpaca Japanでは、2021年8月に「アルパカ証券」という証券サービスをはじめました。 この一連の文章は、アルパカ証券の裏側のシステムやその開発体制などについて述べたものです。なるべく証券分野に限らず説明していく予定ですので、証券サービスを立ち上げようとしている人たちにはもちろん、それ以外の方にも参考にしていただけるような文章を目指したいと思っています。 アルパカ証券とはアルパカ証券の詳細はホームページをご覧ください。また、第一種金融商品取引業者登録完了時のプレスリリースにも、「アルパカ証券」サービスの特徴が記載されています。 全体設計方針まず最初に、アルパカ証券を構成するシステムの全体設計方針について説明します。 マイクロサービス vs モノリシック設計は2018年中頃ぐらいから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microservices Architect in DMM Platform - DMM inside
FargateとLambdaで作るスケーラブルなE2Eテスト実行基盤 / Building a scalable E2E test execution platform with AWS Fargate and Lambda
