Action-Domain-Responder
https://github.com/pmjones/mvc-refinement Here is my random thought about ADR. It seems the each component seems to have their own each distinct and meaningful role. Devs will follow a more natural workflow with it. Domains become first class citizens compared to a “data provider” to their GOD controller in some MVC framework. I like the fact that an action returns a responder (not actually invoki
第2回 三層アーキテクチャとは | gihyo.jp
三層アーキテクチャモデル 今回は従来から一般的に言われている三層アーキテクチャモデルについて説明します。 三層アーキテクチャはメインフレーム上でのレガシーシステム時代から提唱され、さまざまな形になってきています。まず、プレゼンテーションレイヤ、ビジネスレイヤ、データレイヤの三層に分ける代表的な例を説明いたします。 ① プレゼンテーションレイヤ層 この階層はシステム操作するユーザに対してのユーザへのインターフェイスを提供します。 この階層にはユーザインターフェイスコンポーネントおよびユーザインターフェイスプロセスコンポーネントが含まれます。 ② ビジネスレイヤ層 この階層にはプレゼンテーションレイヤからデータなどが渡され、業務処理を実行します。 プレゼンテーションからのデータ授受をシンプルにかつ柔軟にするためにサービスインターフェイスを設計します。 ビジネスレイヤでは業務処理を実行するためビ
階層アーキテクチャの利点は、複雑さの減少 ― ＠IT
個々のコンポーネントを組み上げて、どのようなシステムを構築するか。構造（アーキテクチャ）によって、できあがるシステムの性質が変わってくる。作り手側の視点に立てば、どのようなアーキテクチャを採用するかによって、作り方も変わってくる。いままで連載した記事を通して、わたしたちは、個々のコンポーネントの作り方を学んできた。今回からは、コンポーネントをいかに組み上げるか、という課題に知恵を絞ることになる。コンポーネントの利点を最大限に生かすこと。それがアーキテクチャ設計の現実的な意味の1つだ。そして、1つの有効なアプローチに階層化アーキテクチャがある。 前回「使いやすくて、変化に強いコンポーネント」までにサブシステムなどを利用したコンポーネントの作り方についてお話ししてきました。それでは、コンポーネントは実際どのような単位で作り上げていけばよいのでしょうか。 コンポーネントの単位として考えられるのは
Beyond MVC
PHP Advent Calendar 2013 - 6日目 昨日は@fivestrさんのComposerを使った簡単Travis CI設定でした。 TL;DR オブジェクト指向/MVCでうまく捉えきれていなかったものは何なのか？MVCから続くソフトウェアアーキテクチャーの「その先」は何なのか？Reenskaug博士を知っていますか？ WikipediaによればReenskaug博士は1930年生まれ。MVCという概念が世の中に送り出された論文『MODELS - VIEWS - CONTROLLERS (pdf)』は1979年ですから、49歳の時ということになります。1960年からソフトウェアを書き始め、1973年からオブジェクト指向でソフトウェアを開発しており、現在でも現役でソフトウェアの世界にいらっしゃいます（ex 2009年の講演）。「プログラマ歴42年 (* Clean Coder
AVOIDING THE MUD // Speaker Deck
All slide content and descriptions are owned by their creators.
RMR Architecture
RMR involves implementing your application in terms of the following concepts: Resource: An object that can be addressed via a HTTP request Methods: The ways in which a Resource can respond to particular types of HTTP requests. Representation: The data that is returned to the initiating actor once the Resource has generated output. A typical request/response cycle should run through the following
DCIアーキテクチャへの違和感から見えてくるユースケースDSL - 石橋秀仁(zerobase)書き散らす
DCIとDDD DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticismを読んだり、DCI meetup w/ @jcoplien for Rubyistsに参加したりして、DCIアーキテクチャについて考えてきた。 DCIはメッセージパッシング指向だ。そのSmalltalk的なオブジェクト指向の原理はいいけど、実装が嫌だ。 そもそも、DCIアーキテクチャ提唱の目的は、メンタルモデルのセマンティクス・ギャップを埋めることだ。DDDの「ユビキタス言語」も、メンタルモデルのセマンティクス・ギャップを埋めるための要素であり手法だ。だから、ふつうにDDD（ドメイン駆動設計）をやればいいと思った。 DCIへの疑問 DCIでは、「オブジェクトのアイデンティティ」にこだわりすぎていることで、アーキテクチャが複雑になって
The Clean Architecture
In the weeks since I started talking about the need to clean up our architecture, I’ve noticed a surprising resistance to the idea. Apparently the notion that it’s a good idea to hide the framework, UI, or database from the application code is not universally accepted. I first blogged about this topic here , I did a whole cleancoders.com episode on the topic. I’ve also done several keynotes on the
シンプルさの必要性 · eed3si9n
2013-06-24 2012年4月23日にテキサスの Austin で行われた RailsConf 2012 での Rich Hickey (@richhickey) さんによる基調講演、Simplicity Matters を書き起こして翻訳しました。 Rich Hickey さんは Clojure や Datomic の作者です。 この翻訳は Creative Commons Attribution ShareAlike 3.0 ライセンスに基いて公開します。 Rich Hickey 講演 e.e d3si9n 訳 談: こんにちは。ご招待いただきありがとうございます。 聞く所によると RailsConf はいつもコミュニティーからかなり外れた人を選ぶらしく、今回は僕ということになりました。 僕の電話ボックスは外に駐車してあります。(会場、笑) だけど、今日は言語の壁を越える話題を持
PHP Master | Living Apart Together: Decoupling Code and Framework
Of course you develop using the latest technologies and frameworks. You’ve written 2.5 frameworks yourself, your code is PSR-2 compliant, fully unit-tested, has an accompanying PHPMD and PHPCS config, and may even ship with proper documentation (really, that exists!). When a new version of your favorite framework is released, you’ve already used it in your own toy project and submitted a couple of
Martin Fowler's Bliki in Japanese - レイヤリングの原則
http://martinfowler.com/bliki/LayeringPrinciples.html ここ数日、ノルウェーで開かれたエンタープライズソフトウェアのワークショップに参加してきました。Jimmy Nilssonが主催するワークショップです。 そのなかで、いくつかの設計原則を挙げ、それに投票するというセッションを行いました。 ルールはこうです。 まず、レイヤリングに関する原則をみんなでリストアップしていきます。 次に、簡単なディスカッションを行います（各項目を明確にします）。 自分が好きだろうが嫌いだろが関係なく、 とにかく現場で聞いたことのある原則を残らず挙げていくのが、ここでのルールです。 リストができあがると、投票の時間です。 我々はドット投票の変形を使いました。 各自が賛成票と反対票をそれぞれ10票ずつ持つというものです。 以下に投票結果を掲載しました。 原則の後ろ
)
Microsoft Application Architecture Guide, 2nd Edition
patterns & practices Developer Center October 2009 This guide is available online here in the MSDN Library and as a Microsoft Press book, ISBN# 9780735627109, that you can purchase through local and online booksellers such as Amazon, Barnes & Noble and BORDERS. The guide is intended to help developers and solution architects design and build effective, high quality applications using the Microsoft
Microsoft – クラウド、コンピューター、アプリ & ゲーム
すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox Live Gold Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform W
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hexagonal Architecture
Agility and the essence of software architecture by Simon Brown [PDF]
10月にベルリンにおける最初のGOTOカンファレンスがやって来る
SymfonyLive London 2013 - Igor Wiedler - The HttpKernelInterface is a lie
The framework as an implementation detail
アーキテクチャの目的は意図であり、フレームワークではない
http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf