変化に適応するソフトウェアアーキテクチャと組織構造への道程 - クラウドワークス エンジニアブログ
年の瀬ご多端の折、皆様におかれましては本年も大変お世話になりました。crowdworks.jpの開発をしているプロダクト開発部部長兼VPoEの@hihats です。 本記事はクラウドワークスAdvent Calendar 2022 24日目の記事です。 我々の組織ではこれまでも技術的負債解消に取り組んできていましたが、今期（10月）よりさらに人と時間をそこに集中しています。これまでこのブログでも紹介されてきたようにRuby on Railsのモノリスとなっているcrowdworks.jpにおいて、フロントエンドのVue.jsへの移行は今年に入ってから着々と進む中、バックエンドのほうは保守性の低下からどう脱却していくかが手付かずに近い状態でした。 この本丸を攻略するにあたって、闇雲にリファクタリングしていくぞ！では到底うまくいきそうにない。まず「何故やるのか、何をゴールとするのか」の意識あわ
イベント駆動アーキテクチャの勘所 - エムスリーテックブログ
こちらはエムスリーAdvent Calendar 2022の24日目の記事です。 こんにちは、デジスマチームの田口(id:ken-tunc)です。 私達のチームではQRコードによる受付や自動後払いなど、新しい診療体験を提供するデジスマ診療というサービスを開発しています。 開発メンバー6人と小規模のチームですが、毎週のように新機能をリリースしています。 また、ユーザー数も非線形的な成長を遂げており、システムのトランザクションは日に日に増加しています。 IR資料「2023年3月期第2四半期決算発表資料」より このようなスピード感のある開発を実現できている要因はいくつかありますが、この記事ではそのうちの1つであろうデジスマチームで採用しているアーキテクチャについてまとめていきます。 デジスマ診療のアーキテクチャ デジスマチーム紹介資料 イベント駆動アーキテクチャの設計で気を付けていること イベン
データベースと向き合う決意 | フューチャー技術ブログ
秋のブログ週間の9本目のエントリーになります。この企画もこんなに書く人が出てくるように育っていいですね。 「中間層を増やして柔軟性を高めるのがソフトウェアの歴史」 これは大学時代に2つ上の先輩が言っていた言葉です。例えばマシン語を直接書くのではなく、アセンブラで書けば、変換（コンパイル）の手間はかかりますが、他のCPUへの移植はしやすくなります。高級アセンブラと名高いC言語を使えばさらに移植性は上がります。C言語で書かれたVMを使う言語、例えばJava、Python、Rubyなんかはさらに移植性は上がります。 ストレージもそうです。最終的にストレージはビット列を保存するものですが、それにOSのファイルシステムというレイヤーがあり、そこにスキーマで管理されたデータを入れるDBMSが乗っかり、SQLなどの問い合わせ言語でデータ取得できるようにします。DBMSを挟むことで、レプリケーションでバッ
『ソフトウェアアーキテクチャ・ハードパーツーー分散アーキテクチャのためのトレードオフ分析』 - snoozer05's blog
翻訳を担当した書籍『ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析』（オライリー・ジャパン）が本日（10月27日）発売となります（電子書籍はオライリー・ジャパンのサイトから購入できます）。本書は、2021年10月に出版されたNeal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani 著『Software Architecture: The Hard Parts』（O'Reilly Media）を全訳したものです。 ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析 作者:Neal Ford,Mark Richards,Pramod Sadalage,Zhamak DehghaniオライリージャパンAmazon 本書は、『ソフトウェアアーキテクチャの基礎 ―エ
設計の考え方とやり方
#asken_dev「設計の考え方とやり方」勉強会 https://asken.connpass.com/event/254709/ ・良い設計は悪い設計より変更が楽で安全である ・ドメインモデル方式のクラス設計 ・イミュータブル方式のテーブル設計 ・設計スキルの身につけかた ・設計の…
アーキテクチャと設計は全然違う⋯ただしあなたの想像する”違い”とは多分全然違う【輪読会発表紹介】 - エムスリーテックブログ
エムスリーエンジニアリンググループ製薬企業向けプラットフォームチームの三浦 (@yuba)です。エンジニアリンググループ内では技術書の輪読会が有志によりいくつか立ち上がっています*1。そうした勉強会の一つで発表した内容が社内で少々バズったので、これは社内だけじゃもったいないとご紹介させていただきます。 本は、「ソフトウェアアーキテクチャの基礎（オライリー・ジャパン、Mark Richards/Neal Ford著 島田浩二訳）」。その第2章です。 謝辞をまず この章は 知識の”幅”と”深さ”だ 幅広さ→候補とメリデメ→ビジネス動機に即した判断 深さ→最新アップデートに追いつき続けること→偏らない判断 まとめ 参加者の感想など We are hiring! ソフトウェア アーキテクチャ基礎 輪読会資料 第2章 アーキテクチャ思考 from 琢磨 三浦 謝辞をまず この本の輪読会を立ち上げてく
メモ:値オブジェクトの定義と差異について - かとじゅんの技術日誌
「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。 すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。 もし読むなら興味がある人だけで。 自分向けのメモですが、一応 この記事の前提や意図を書いておきます。 「DDDの値オブジェクト」以外を否定する記事ではありません。 原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか 下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。 言い訳と
クラウド アプリケーションのベスト プラクティス - Azure Architecture Center
これらのベスト プラクティスは、信頼性が高く、スケーラブルで、セキュリティで保護されたアプリケーションをクラウドに構築するのに役立ちます。 これらは、効率的で堅牢なシステム、メカニズム、およびアプローチを設計および実装するためのガイドラインとヒントを提供します。 多くは、Azure サービスで使用できるコード例も含まれています。 このプラクティスは、ホストが Azure か別のクラウド プラットフォームかにかかわらず、すべての分散システムに適用されます。 プラクティスのカタログ 次の表に、さまざまなベスト プラクティスを示します。 関連する柱 列には、プラクティスが重点を置いている Microsoft Azure Well-Architected フレームワーク の柱が含まれています。 練習 概要 関連する柱
『ソフトウェアアーキテクチャの基礎』は我々の海図たりえるか
こんにちは、クレスウェア株式会社の奥野賢太郎 ( @okunokentaro ) です。今回は、最近噂としてよく耳にしていた書籍『ソフトウェアアーキテクチャの基礎 ― エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン社、Mark Richards, Neal Ford 著、島田浩二 訳、2022 年 3 月発行）を読了したので、その書評をまとめようかと思います。 この書籍は、アプリケーション・アーキテクチャを構築、維持する「アーキテクト」になるために必要な知識を現代（2020 年代）の視点から整理し、包括的に解説することを目的としているらしく、まさに 2022 年に読むべき内容に仕上がっています。 書評者は何者か この書籍はよいものでした。ただし、かなり広範囲に包括的に書かれたものであったため、どういう経験や知識を持った人間が読んだかによって、その好みや評価は分かれるだろう
『ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ』を読めばアーキテクトになれるのだろうか - Magnolia Tech
ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ 作者:Mark Richards,Neal FordオライリージャパンAmazon とても良い本だ！アーキテクチャのパターンは体系的に整理されているし、アーキテクチャを議論する上で、共通の語彙となり得る用語を解説している（コンウェイの法則や、凝集度など）。 後半は、リスクや、チームビルディング、交渉術まで多岐に渡るトピックを網羅している。 必要なことは全部書いてある...けれど、なんとなく初めてPMBOKを読んだときに抱いた感想...読み始めてからすぐに「果たしてこの本に書かれている通りの考え方に沿って振る舞えばアーキテクトになれるのか？」という気持ちになりはじめたところで1章の最後の方に出てくる「ソフトウェアアーキテクチャの法則」が出てきて、「そうだよなー」という気持ちに。 ソフトウェアアーキテクチャはトレード
「SwiftUIでMVVMを採用するのは止めよう」と思い至った理由 - Qiita
宣言的UIの登場で、ViewModelは、存在理由を失っている つまり、 SwiftUIにViewModelのデータバインディング機能が内包された時点で、 ViewModelは存在理由を失い、「ViewModel」という言葉自体も、なんだか意味がよくわからない言葉 になってしまいました。 ViewModelという言葉は 非常に曖昧 で人によって定義が違い、そもそもViewModelレイヤーでやるべきことが何なのか明確化されてないので、とりあえず面倒事は全部押し付けられがちです。 本来、別のレイヤーですべきこともViewModelにつっこんでたりします。 MVVMを採用すると余計な複雑性を生んでしまう。 SwiftUIでMVVMを採用してしまうと「ViewModel」という余計なレイヤーを挟んでしまうため、冗長で複雑になります。 データフローについて、ViewとModelがViewModel
『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』 - snoozer05's blog
翻訳を担当した書籍『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン）が3月8日に発売されます。本書は、2020年1月に出版されたMark Richards, Neal Ford著『Fundamentals of Software Architecture』（O'Reilly Media）を全訳したものです。 www.oreilly.co.jp ソフトウェアアーキテクチャとは、ソフトウェアシステムの成功に欠かせない重要な土台です。そのためソフトウェア開発者には、効果的なアーキテクチャを実現するスキルが求められます。本書は、そうした効果的なアーキテクチャを設計、構築、維持するアーキテクトになるために必要なスキルや知識を、現代的な視点から整理して包括的に解説する書籍です。 ソフトウェアアーキテクチャの定義から、アーキテクトの役割、モジュールや
最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita
TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一本槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる「イベントストーミング」がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で「結構日本でやられている取り組みとちがうなー」と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守（あるいは鹿鳴館精神）ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基本線となりつつある、、、のか？ まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも「ドメインイベント」として実装パタ
Clean Architecture on Frontend （翻訳） - Qiita
こちらはDEV Communityに2021年9月2日に投稿され、現在反響を巻き起こしているフロントエンドにおけるクリーンアーキテクチャの実装についてのAlexさんの記事になります（原文はこちら)(twitterにて翻訳掲載許可取得済み）。 かなり大ボリュームな超大作記事となっておりますが、Reactなどを使ったフロントエンドプロジェクトのディレクトリー構成やファイルごとの責務の切り分けのベストプラクティスなどの決定版といえるものがまだまだ出てこない中で、個人的にまさに待ち侘びていたような内容の記事かと思い、是非日本のフロントエンドコミュニティでも知見が共有されればと思いました。 それでは以下、本文です。 *翻訳は大部分をDeepL翻訳によって行っていますが、適宜修正してあります。 少し前に、私はフロントエンドにおけるクリーンアーキテクチャについての講演を行いました。この記事では、その講演
クリーンアーキテクチャなんてものはない(クリーンアーキテクチャーの読み方)
すでに何人かの人がクリーンアーキテクチャなんてないよ、って話はしていてイマサラだと思うんですが。 あえてブログの記事に残そうかなと思って書いてみます。 最近、改めてクリーンアーキテクチャ本を読んだり、原文を読んだり、 ここ数ヶ月ツイート色々な人のを観測したり社内で話したりしていて 考えがまとまってきたので、自分の言葉で整理してみたくなった。 「へー、クリーンアーキテクチャっていうソフトウェアアーキテクチャがあるんだー」という微妙な誤解？をちょっとでも減らす一助になればという感じです。あと、本の読み進め方のヒントにもなるかも 先に結論 クリーンアーキテクチャというのはアンクルボブの書いた本。 ソフトウェアアーキテクチャのことではない。 the クリーンアーキテクチャというブログ記事はただのソフトウェアアーキテクチャの例(そして本の一部分)だが、独り歩きしている クリーンアーキテクチャというソ
実践！ Typescript で DDD - マイクロサービス設計のすすめ - Leverages Tech Blog
対象読者 マイクロサービス化を検討しており、実際に作る場合の構成を参考にしたい。 ドメイン駆動設計について、基本的な用語の知識がある。 TypeScript を多少触ったことがある。理解がある。 はじめに こんにちは。エンジニアの吉村です。 現在、弊社が運営する teratail というサービスに携わっており、CakePHP で動作しているモノリシックな既存サービスをマイクロサービスに移行するというプロジェクトを進行中です。 この記事では、実務を通して得た知見として、マイクロサービス化によりどんな恩恵があるのか、具体的にどのような構成で実装をしているのかについてご紹介します。 TL;DR マイクロサービスのバックエンドサービスの実装に焦点を絞って、ドメイン駆動設計 + オニオンアーキテクチャをベースに設計をしました。 本記事では、具体的に「ユーザ新規登録処理」の実装をする場合を例にとり、実
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/at_sushi_/status/1592673880313057280
ソフトウェアアーキテクチャの基礎: Software Architecture in a Nutshell
建築設計10年にして一級建築士・１級建築施工管理技士の資格を持つ有名なエロ漫画家「鬼ノ仁」さんがついに建築マンガ「一級建築士矩子の設計思考」を発売！
