進化的アーキテクチャ
現代におけるエンタープライズアーキテクチャは、もはや静的な計画をあてにすることはできなくなっています。そしてソフトウェア開発エコシステムは、ツールやフレームワーク、技術イノベーションの流れと共に絶え間なく変化しています。こうした状況の中で、いったん構築したシステムを成長させていくには、さまざまな変化に適応しながら進化するアーキテクチャをシステムに組み込む必要があります。本書は、そうしたアーキテクチャを「進化的アーキテクチャ」と名付け、その構築に必要な考え方や技術、実践方法などについて解説するものです。 ThoughtWorksの3人のスペシャリストから現代のソフトウェアアーキテクトに向けられた本書は、絶え間ない変化を支える進化的アーキテクチャを構築するために必要なすべてを提供する実践的なガイドです。 本書への推薦の言葉 訳者まえがき マーチン・ファウラーによる序文 はじめに 1章 ソフトウ
進化的アーキテクチャ
現代におけるエンタープライズアーキテクチャは、もはや静的な計画をあてにすることはできなくなっています。そしてソフトウェア開発エコシステムは、ツールやフレームワーク、技術イノベーションの流れと共に絶え間なく変化しています。こうした状況の中で、いったん構築したシステムを成長させていくには、さまざまな変化に適応しながら進化するアーキテクチャをシステムに組み込む必要があります。本書は、そうしたアーキテクチャを「進化的アーキテクチャ」と名付け、その構築に必要な考え方や技術、実践方法などについて解説するものです。 ThoughtWorksの3人のスペシャリストから現代のソフトウェアアーキテクトに向けられた本書は、絶え間ない変化を支える進化的アーキテクチャを構築するために必要なすべてを提供する実践的なガイドです。 本書への推薦の言葉 訳者まえがき マーチン・ファウラーによる序文 はじめに 1章 ソフトウ
ドメイン駆動設計をはじめよう
ドメイン駆動設計はエリック・エヴァンスにより提唱されたソフトウェア設計の手法です。対象とする事業活動（ドメイン）とその課題の観点から、より良いソフトウェアを構築するために関係者が協力する方法を提供します。本書は4部構成になっており、第Ⅰ部「設計の基本方針」では、ソフトウェアの設計方針を大きな視点から決めるための考え方とやり方を取り上げます。第Ⅱ部「実装方法の選択」ではソースコードに焦点を合わせ、業務ロジックをどう実装するかの選択肢を学びます。第Ⅲ部「ドメイン駆動設計の実践」では、ソフトウェア開発の現場にドメイン駆動設計を実践的に取り入れるための方法を紹介します。第Ⅳ部「他の方法論や設計技法との関係」では、ドメイン駆動設計とそれ以外の方法論や設計技法との関係を検討します。最新の技術トレンドを取り入れながら、ドメイン駆動設計の基本概念と実践方法をわかりやすく解説します。 正誤表 ここで紹介する
脳に収まるコードの書き方
ソフトウェアは複雑さを増すばかりですが、人間の脳は限られた複雑さしか扱えません。ソフトウェアが思い通りに動くようするには、脳に収まり、人間が理解できるコードを書く必要があります。 本書は、拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践的な方法を解説します。最初のコードを書き始めるところから機能を追加していくところまでを解説し、効率的で持続可能なペースを保ちながら、横断的な問題への対処やトラブルシューティング、最適化を行なう方法を説明します。自分のチェックリストからチームワーク、カプセル化から分解、API設計から単体テストまで、ソフトウエア開発の重要な課題に対する考え方やテクニックを紹介します。サンプルプロジェクトで使うコードは、Gitリポジトリの形で入手でき、試しながら学べます。 有効に機能するプロセスを選び、効果のない方法論から脱却する方法。チェックリストを使うこ
ソフトウェアアーキテクチャメトリクス
ソフトウェア品質をプロセスの早い段階から計測し、アーキテクチャの負債や技術的負債の蓄積を検知できるようにしておくことは、ソフトウェアの成功にとって重要です。ソフトウェアアーキテクチャに関するメトリクスを適切に導入できれば、パフォーマンスなどのリスクを軽減し、問題に対処するコストを抑えられます。 本書は、経験豊かな10人のソフトウェアアーキテクトたちが、知っておくべきメトリクスについて、貴重な経験やケーススタディと共に紹介します。 アーキテクチャが目標にどれだけ合致しているかの計測、追跡すべき適切なメトリクスの選択、可観測性/テスト容易性/デプロイ可能性を向上させる方法、アーキテクチャに対する取り組みの優先順位付け、学びに満ちた適切なダッシュボードの構築を解説します。 はじめに 1章 解き放たれた4つのキーメトリクス1.1定義と計測 1.2 メンタルモデルのリファクタリング 1.2.1 最初
ソフトウェア設計のトレードオフと誤りを出版しました | フューチャー技術ブログ
すでに多くの方々にお手に取っていただいておりますが、オライリージャパンから「ソフトウェア設計のトレードオフと誤り」の翻訳をフューチャーのメンバーと一緒に出版いたしました。好評なようで、発売一カ月ほどで増刷も決定いたしました。みなさまご購入いただき、ありがとうございます。初版をお買い求めになられたい方は今すぐ書店にダッシュ！ トレードオフこそが設計である良い設計とか読みやすいコードみたいな話題はツイッターではバズりやすい話題です。 読みやすいコードの話題ではいろいろなレイヤーの話が出てくるのですが、因数分解すると、だいたいいくつかのカテゴリーに分かれるように思います。 命名規則とか書き方のルール 従うべきクラス構造、アーキテクチャ構成の導入 サービスの境界をどこに引くか、どのようなときに設計手法を選ぶか、どのアルゴリズムを選ぶか 名前や命名規則の統一とか書き方の統一とかは用語のリストを作って
システム運用アンチパターン
上層部がDevOpsに理解のない組織で働き、組織構造を変える権限を持っていない開発者であっても、チームにDevOpsを導入するための現実的な方法を紹介します。 重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説します。 組織で必要とされる変化を、エンジニアが行動することで実現する本書は、ソフトウェアシステムをよりよく開発運用したいエンジニア必携の一冊です。 目 次 序文 本書について 1章 DevOpsを構成するもの 1.1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
