本記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。 第1部 イントロダクション ソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。 ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。 「あとでクリーンにすればいいよ。先に市場に出さなければ！」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。 すべてのソフトウェアシステムは、2
はじめに この記事では、以前私たちが実際に関わった開発案件で作成した「アーキテクチャドキュメント」を公開します。 別に国宝のお寺の庭に入れるわけでもないのに、「特別公開！」などという表現はずいぶん仰々しいな、と思われる方もいらっしゃるかもしれません。しかし特定のお客様向けに作成し納品したドキュメントを、そのまま外部に公開してしまうような例を、私自身はあまり聞いたことがありません。 これって結構特別だと思うのですが、手前味噌でしょうか？ システムの概要 ご紹介する開発案件の名称は「新石炭総合ＯＡシステム」といいます。これは、宇部興産株式会社殿で使われる社内システムで、在庫管理、販売管理などの機能を提供する典型的なビジネスアプリケーションです。 開発主体は株式会社宇部情報システム殿です。弊社（オージス総研）は、プロジェクトの立ち上げ期間の約３ヶ月間、２名が参加し、概念モデリングのコンサルティン
先日、マイクロサービスの呼び出し方として、オーケストレーションとコレオグラフィについて書きましたが、同じく4章では、どうHTMLを組み立てるかという問題が提起されています。 ここもやや難解なので、咀嚼を試みます。 課題設定 次のようなECサイトを考えることにします。そして、4つのマイクロサービスを合成して構成します。 商品カタログサービス ショッピングカートサービス ショップサービス リコメンドサービス API合成 無垢な気持ちで設計すると、各々のマイクロサービスがWeb APIのインタフェースをもち、XMLやJSONを返して、ECサイト側で、テンプレートエンジンなどを用いて、HTMLをレンダリングするという方式になるかと思います。 そして、この形式でマイクロサービスを利用するサイト(アプリケーション)が増えていくと次の図のようになります。 これには、次の3つの欠点があるとされています。
Yahooの技術者が書いたブログ techblog.yahoo.co.jp が悪い方向に期待を裏切ってくれたのに対し、 @kuenishi さんがまとまった文章 kuenishi.hatenadiary.jp を書いていたので、僕も2番煎じぐらいでまとまった文章を書く。 始めに断っておくと、分散システムというのはまだまだ事例を集めていくフェーズを抜けきっておらず、体系立った大統一理論的な分類法は確立していない。ここに書くのは、これまでの分散システム事例やこれからの分散システム事例を分類していく際にその性質をカテゴライズする一助となれば良いな、程度の文章なのであまり真に受けないで欲しい。 なぜYahooの記事が期待はずれなのか 人によって意見はあるとは思うが、個人的に感じたのは以下の３つ。 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじ
特定のプロジェクトがあり、要件定義をし概要設計をする。 それがアーキテクトの仕事だと思われがちですが、大きな視点を持ち様々な課題を自らリードして解決していく立場としても絶好のポジションです。 このセッションでは、Mobage オープンプラットフォームの立ち上げから、 グローバルプラットフォーム展開、さらには mixi 社との共同プラットフォーム構築、 JavaScript SDK と認証技術の組み合わせによる新しい HTML5 プラットフォーム構築をアーキテクトという立場でリードし続けた立場から、技術選択のみならず実現したい事に対する俯瞰的な捉え方を、これまでの実例と共に紹介し、アーキテクトという役割について、お話します。
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog saegusa2017-04-16Yoshihiro was a network engineer at LINE, responsible for all levels of LINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to apply LINE's technology and business goals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回
Lock, Concurrency and Throughput of Exclusive Operations
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存
モデルの表現方法の一つとしてDCIの実装方法を、いろいろと模索しています。 暗黙的型変換と型クラスを使ったDCIがよいと説明しましたが、traitだけでもっと簡単に実現できないか考えてみました(この方法はLean Architectureにも紹介されている実装方式です)。 traitで仕様を表現する traitは、仕様を表現するためのインターフェイスとしても使えるし、他のクラスなどに合成するための、再利用可能な実装(部分クラスなどと言われることがある)としても使えます。 DCIとは直接関係ない話ですが、まずtraitのインターフェイス的な使い方からいきます。 では、お決まりの銀行口座で説明(好きやなーw)。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 // 銀行口座エンティティ // 不変条件: 残高の量は負数であってはならな
はじめに この連載では、「オープンソースApache Tuscanyで楽しむSOA」として、オープンソースのSCA準拠製品である「Apache Tuscany」を取り上げ、SOA（サービス指向アーキテクチャ）の開発について説明していきたいと思います。第1回目の今回は、Tuscanyの誕生までの歴史と、Tuscanyとは何かを紹介していきます。 「楽しむ」という言葉に反応された方も多いでしょう。「SOAって楽しめるわけがない」「Webサービスの膨大な仕様書があるけどよくわからなかった」「簡単なことをやる割には、SOAPとかWSDLとか結構面倒だし」という声が聞こえてきそうです。そこなんです、当連載の目的は。Tuscanyは膨大なWebサービスの仕様書を読まなくても開発できます。Webサービスの面倒な部分はコンテナが勝手にやってくれます。JSONやATOMを使ったAjaxについてもほとんど知識
アーキテクチャとは何だろうか？この問いはいろいろな人に聞くといろいろな答えが返ってくるので、「リクルートの面接時に必ず問う」という人もいるはずだ。ソフトウェアと分野に限らなくてもよいし、さらに、システムという分野に限らなくても答えられる。 ぼくの知識の中で、もっともらしいと思われているのが幾つかある。 IEEE1471のアーキテクチャに関するコンセプチャルなフレームワーク これは、図のようなモデルで表現される。これは、かなりフォーマルに「アーキテクチャとは何か？」に答えているようだ。システムには１つのアーキテクチャがあり、１つ以上のアーキテクチャ記述によって記述されており、１つ以上のビューとモデルを含み、ステークホルダと関連している。ステークホルダは１つ以上の関心事をもっており、１つの視点は１つ以上の関心事をカバーしている。。。。。。」と読む（読めるか？）。 RUP RUPは、それ自身、「
この記事はTrygve Reenskaug氏の記事「MODELS - VIEWS - CONTROLLERS」を、氏の許可を得て翻訳したものです。（原文公開日：1979年12月10日） モデル モデルは知識の表象です。モデルは１つのオブジェクトであるかもしれませし（あまり面白くはありませんが）、複数のオブジェクトからなる構造かもしれません。 モデルとその一部には一対一の対応関係がある一方で、モデルとその所有者によって知覚された世界の表象との間にも一対一の対応関係があります。したがって、モデルの各ノードはその問題における識別可能な一部分を表象しているのです。 モデルの各ノードは、同一水準の問題を扱うものでなければなりません。問題指向の各ノード（例えば、カレンダーの予定）を実装の詳細（例えば、パラグラフ）と一緒にすることは混乱を招きますし、良くない形式と考えられます。 ビュー ビューはモデルの
みなさん、Evernoteは使っていますか？ Evernoteは「全てを記憶する」が合言葉のメモアプリで、クラウド上にデータを保存してWin/Mac/iPhone/Webから共通のデータにアクセスしたり同期したりできるのが特徴の便利なサービスです。開発元はシリコンバレーの会社ですが、日本人のユーザも非常に多いそうで、Evernoteの使い方についての記事は日本語でも星の数ほどありますのでここでは触れません。 今回は、そのEvernoteの裏側のシステム概要を解説する記事が今月開設されたばかりの技術ブログに公開されていましたので、翻訳してみました。Architectural Digest | Evernote Tech Blog はじめにこのブログの手始めとして、Evernoteの構築について大雑把な概要を述べる。ここではそれぞれのコンポーネントの詳細に踏み込むことはしない。それらについての
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く