Clean Architectureは全てのプログラマにお奨めしたい良著｜erukiti
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。 続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。併せてご覧ください。 なぜ良著？著者のロバート・Ｃ・マーチン（著書読んだことあるかも？）は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基本部分は変わらないと言ってて、それらが美味くまとまった本だからです。 いってみればコンピュータ工学について抑えるべきポイントを解説した本であり、The Clean Architectureそのものについてはほとんど割かれていません。それくらい、基本として知るべき事が書かれた本なのです。 最近のアーキテクチャを追いか
実践クリーンアーキテクチャ │ nrslib
YouTube での解説 YouTube にて Java コードをベースに解説を行いました。 コードの雰囲気は C# とほとんど同じなので参考になるかと思います。 もしよければご覧ください。 Java コードの記事リンク：https://nrslib.com/clean-architecture-with-java/ その他解説もしています。もしよろしければチャンネル登録をお願いいたします。 Qiita 版 Qiita に CUI や GUI 向けのクリーンアーキテクチャの記事を書きました。 ボブおじさんのクラス図を模したものです。 Web とはまた異なった実装になるので、もしよければ合わせてご参照ください。 https://qiita.com/nrslib/items/a5f902c4defc83bd46b8 さらに PHP の Laravel 版も作ってみました。 https://qi
Clean Architectureで分からなかったところを整理する - Qiita
ちょっと前にiOS allstars2に参加して知ったClean Architecture(クリーンアーキテクチャ)が、最初はなるほどすげえなーと思っていたものの、ちょっと改めて調べてたら少し迷子になったので自分のために色々整理してみる。 そもそもクリーンアーキテクチャの前に クリーンアーキテクチャのことを書いているエントリーを見るとよくMVC, MVVMなどのアーキテクチャとの比較があるが、一緒に丸が４層になった絵が出てくる。（本家はこちらですが、日本語訳をされた方のエントリもある。） 自分はいきなりこの絵をみても何のことやらだった。が、この絵はオニオンアーキテクチャ、ヘキサゴナルアーキテクチャを知ると理解できた。 ヘキサゴナルアーキテクチャ (Hexagonal Architecture) ヘキサゴナルアーキテクチャは、伝統的なMVC, MVVMなどのレイヤード（階層）アーキテクチャか
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
実装クリーンアーキテクチャ
最近何かと騒がしいクリーンアーキテクチャですが、丁度プロダクトで採用したところだったので折角なので情報共有ということで Qiita の初記事にしてみようと思います。 こちらの記事は GUI や CUI のアプリケーションを対象にしています。 Java コードの記事リンク：https://nrslib.com/clean-architecture-with-java/?preview_id=1263&preview_nonce=542ba7b70f&_thumbnail_id=1293&preview=true その他解説もしています。もしよろしければチャンネル登録をお願いいたします。 より実践的なコード（WEBアプリケーション）: https://github.com/nrslib/itddd/tree/master/CleanLike YouTube での解説（WEBアプリケーション）：
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
アーキテクトの審美眼
MS萩原さんのセッション。同名の書籍（元ネタはDBマガジンの同名の連載）が元になっていて、そのダイジェスト版＋最新の動向の補足、という形。とても示唆に富んでいるんだけど、抽象的な上に、1つ1つのトピックがめちゃめちゃ重たいので、きちんと理解しようとすると調べる量がとても多くなってしまう上に、そもそも理解しきるのが難しすぎる。とりあえずは現段階の自分の稚拙な理解をもとに、こんなことじゃないかなーと補足しながら書いていく。 アーキテクチャの原則アーキテクトにとっては、アーキテクチャの原則を理解することが重要。アーキテクチャの原則は、インフラなどが変化しても変わらず、クラウドでも通用する。 アーキテクチャ先行定義の原則アーキテクチャは先行定義せねばならぬ、という原則。アーキテクチャ設計を含むソフトウェア開発は、こんな風な流れになるはず。 モデリングとアーキテクチャ設計の双方のインプットとして、シ
開発者が知っておくべき、6つのUIアーキテクチャ・パターン - ＠IT
.NET開発者中心 厳選ブログ記事 開発者が知っておくべき、6つのUIアーキテクチャ・パターン ―― 「matarillo.com」より ―― 猪股 健太郎 2011/12/15 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET／.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 Martin Fowler氏の『GUI Architectures』を訳して公開しようと思ったのだが、FAQページに「PofEAAの続編などは商業出版する予定なので翻訳はしないでほしい」と書いてある。なので翻訳の公開はやめて、「
システム設計日記
テスト駆動開発 和田卓人(t-wada)さんによる『テスト駆動開発』の新訳版が出版されました。 オブジェクト指向でソフトウェアを開発するのであれば、この本とマーチンファウラーの『リファクタリング』は必読書だと思います。この古典ともいえる『テスト駆動開発』が和田さんの手によって新訳版として復刊されたことは、ほんとうにすばらしいことです。 この本が出版された経緯と、和田さんはじめ関係者の方々のご努力については、和田さんの、このブログをぜひ読んでいただければと思います。 新訳版『テスト駆動開発』が出ます 新訳本は、単に原著が日本語で読めるようになっただけではありません。和田さんの手によって、原著にはない新たな価値が付け加えらました。 一つは、サンプルコードの工夫です。 できるだけ省略はしない変更箇所を目立つようにした各章末にその時点での全コードを記載する これらの工夫により、本に書かれた内容が、
サブシステムを「使い捨てる」ためのアーキテクチャ - 設計者の発言
友人から、最近の「薬品卸売業界」の話を聞いた。知られているように、規制緩和によって一部の薬がコンビニや電器量販店でも扱えるようになった。そうすると薬品卸売業としては、多様な販売先に対応したきめ細かい受注・出荷体制や棚割ノウハウの提供が求められるようになる。ところが、規制緩和したからといって国民がいきなり市販薬をより多く買うようになるわけではない。結果的に、新しいタイプの顧客からの売上が増えるいっぽうで、その分だけ既顧客からの売上は減る。 その業界で生き延びてきた企業の多くは、販売管理システムを手作りすることでサービスレベルの向上をはかってきた。この経営方針は「サービスレベルを向上させつつ物流コストを抑えるためには、システムを手作りしたほうがまだトータルのコストを抑えられる」という経済合理性にもとづいている。しかし、この方針は売上高が右肩上がりで増大することを前提としている。より多様な顧客へ
Information Architecture Institute > Learning IA - Information Architecture Institute:
We’re currently in the process of migrating our library to the new Drupal system, but in the meantime we’ve made the content available via Google Documents. Our library is the largest expertly-curated, information architecture-specific library in the world, including articles, tools, templates, podcasts, and a full listing of all the books one could ever need to get to the next level of their IA p
適切なアジャイル性を実現するアーキテクチャ (arclamp.jp アークランプ)
先日、憧れのITアーキテクトと「アジャイル・アーキテクチャ」について議論。きちんと理想と現実と捉えていて、さすがという感じでした。 アーキテクチャ自身がアジャイルなわけではない まず言われたのが「アジャイルなアーキテクチャ」といってしまうと、アーキテクチャ自体がアジャイルに変化するというミスリードをするのではないかという点。確かにそうですね。広義のアーキテクチャというのは全体性を決定する思想・概念であり、それ自体がアジャイルに変化することが求めることはあまりないと思っています。狭義のアプリケーション・アーキテクチャに変更が求められる場合はありえますが、それすら広義のアーキテクチャには織り込み済みであるべきです。 では、僕らが考えるアジャイル・アーキテクチャとは何か。それは"適切なアジャイル性を実現するアーキテクチャ"と定義できそうです。 ここで出てきたのがアーキテクチャの結合度、可変性分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スケーラブルシステムのデザインパターン