Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
筆者は、このような画面を頻繁に目にします。なぜなら、デザインに疎い筆者自身がWebアプリを開発すると、このようなシンプルな画面がたくさん出来上がるからです。 そもそも業務アプリケーションでは、業務で取り扱う数多くの情報を、データベースや他システムなどから取得し、アプリケーション内でそれらの情報を、安全かつ正確に処理するためのコーディングを行う必要があります。開発規模が大きくなれば、再利用性の高い設計になるようさまざまな知恵を使う必要がありますし、取り扱う情報には機密性の高いものも含まれるため、セキュリティなどにも細心の注意を払う必要があります。そのため、どうしてもビジネスロジックの開発に注力しがちで、画面デザインやレイアウトなどのフロントエンド開発は、ついつい後回しになってしまいます。 しかしながら、Webアプリの操作性は、システムの顧客満足度を左右する重要なポイントになります。また、パソ
アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い
JJUG CCC 2017 Springで論理削除フラグをどうにかするための話をしてきました 【FOLIOスポンサー】 - itohiro73’s blog
JJUG CCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 from Hiroshi Ito 今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。 togetter.com 世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。 たとえば論理削除フラグという名の死亡フラグ - @ledsun blogというエントリを参考にさせていただくと、下記のような要件の例があります。 ・社員が退職（・転
まだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて - Qiita
＜この記事は「Money Forward Advent Calendar 2015」の22日目の記事です＞ この記事は、iOS Clean Architectureと実際にコードへ適用した内容について紹介します。 コードについては、改善の余地があるため随時修正していくと思います。 → github: https://github.com/koutalou/iOS-CleanArchitecture iOS開発においてよくある問題点 「ビジネスロジックはModelに置くべき」と言うが、開発者によって理解や意見がバラバラで統一的な実装ができない 度重なる仕様変更や複雑な仕様に対応するためにViewControllerや特定のModelが肥大化し、ビジネスロジックの本質を見失う MVC,MVP,MVVMだけで考えると、どこかのレイヤが複数の責務を持つことになり依存度の高い複雑なコードが生まれてし
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。ここからは、3層アーキテクチャの典型例について話し、ビジネスロジック層について深掘りして紹介します。前回はこちらから。 3層アーキテクチャ+MVCの通信の流れ 大嶋勇樹氏：こうやって話してくると、具体的に「じゃあコードをどういうふうに書くの？」「どういうクラスで書くの？」ということを疑問に思うかもしれません。派生形やちょっと違う例もいろいろありますが、典型的な例を1個書いています。 （スライドを示して）これが3層アーキテクチャとMVC（Model、View、Controller）ともいえる典型例です。クラス名のつけ方はいろいろあります。これはどういう構造になっているかというと、まずCont
設計ガイドライン
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
CakePHP Modelに関する6つの誤解
CakePHPのModelはActiveRecordライクなDBアクセス方法を提供しており、さらにアソシエーションを設定することにより複数テーブルの値を同時に操作できるなど、DB操作に対するインターフェイスが数多くあります。 ただ「手軽にDB操作ができる」という印象が先行しているゆえ誤解を招くことがあるようです。 1. クラス名に対応したテーブルしか操作できない Modelのクラス名とテーブルを自動でマッピングするのはフレームワークのいわば便利機能です。デフォルトでそのような動作をするだけで、容易に変更することができます。 Model#$useTableにテーブル名を指定すれば任意のテーブルを操作できます。 <?php class Foo extends AppModel { public $useTable = 't_user'; // t_userテーブル } ?> 2. DBを使わな
無限のメモリ空間と絶対に落ちないプロセスを仮定して「ビジネスロジック」をあぶり出す - assertInstanceOf('Engineer', $a_suenami)
先日、前職の上司から「そろそろプロフィールに"詩人"を追加するべきだ」と言われました a-suenami です。今日も今日とて詩人業を行なっていきますよ！ 「ビジネスロジック」とは何か 最近、業務で、比較的中長期的なアーキテクチャの見直しだったり、新機能の設計だったりをさせてもらう機会が増えた。 コンポーネントをどういう風に分割するかとか、それぞれのコンポーネントを主にどのチームでメンテナンスしていくかとか、そういうのを考えるのは楽しい反面、かなり熟慮に熟慮を重ねないといけないものでもあるのでかなり責任を感じるというのもある。 まあ、そんなこんなでいろいろうーんうーんって悩んでいると昔（たぶん DDD コミュニティだと思うけど）誰かに言われた「無限のメモリ空間と絶対に落ちないプロセスがあったとして、それでもそのコードを書かないといけないのならそれがあなたのドメインだ」という言葉だ。 モデリ
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほ
![[DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/5f74c5c72ebd18816032917216eeec82801e95ef/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCREREJTVEJUUzJTgzJTg5JUUzJTgzJUExJUUzJTgyJUE0JUUzJTgzJUIzJUU5JUE3JTg2JUU1JThCJTk1JTIwJTJCJTIwJUUzJTgyJUFBJUUzJTgzJThCJUUzJTgyJUFBJUUzJTgzJUIzJUUzJTgyJUEyJUUzJTgzJUJDJUUzJTgyJUFEJUUzJTgzJTg2JUUzJTgyJUFGJUUzJTgzJTgxJUUzJTgzJUEzJUU2JUE2JTgyJUU3JTk1JUE1JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz05MGViZDg5M2ZkOGVlMDZkMGEyOWVkZWMyN2MxMmFkNg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBsaXR0bGVfaGFuZF9zJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02YmZmYzI2ZTBkMjNhZjllYjRjZTJiYTQwODIzMjhhNA%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Da55a404321a639c6fc4f1c3992cbb2b3)
はてなincだめだったってことかな？
アルバイトの1人も集まらなかったっぽくね。 結局、しなもんとジャックをご挨拶させただけで終わったのかな？ 相変わらず迷走しているようにみえてハラハラするよ。はてなは。 走ってから考える。もしくは走りながら考えるタイプなのか？ 経営層全員？ ｗｗｗ はてなの営業分析とかしてきたけど、相変わらずビジネスロジックがみえない。 みえないというか、何を目指しているのかがまったくみえない。 まだ一昨年の方が「つながるサービス」とか、そういうビジョンがあったきがする。 去年のテーマを振り返ったときに、どう評価していいかわからない。 過去につくったサービスが衰退期にはいったものがでてきて資産が遺産に変わって重荷になりはじめた一年か？ アメリカ目指したのはアツかったんだけどな。 一年でどれくらい経営者としての見識やネットワークが広がったのだろうか。 21人の会社で、東京、京都、アメリカって… いくらなんでも
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。さらに、ビジネスロジック層の役割について深掘りします。前回はこちらから。 リクエストの形式チェックはビジネスロジック層の役割か？ 大嶋勇樹氏：（スライドを示して）続けて「これはビジネスロジック？」（というもの）をもう少し見ていこうと思います。2つ目として、リクエストの形式チェックがあります。 例えば、リクエストの必須パラメーターが足りているかとか、データサイズは決められた範囲内かとか、そういうチェックがあると思いますが、個人的にこれはプレゼンテーション層でチェックすべきものだと思っています。 なぜかというと、リクエストは利用者とのインターフェイス、利用者との境界での約束事に対するチェックな
iOSDC 2017 前夜祭で「節子、それViewControllerやない…、FatViewControllerや…。」というタイトルで登壇しました！ #iosdc | DevelopersIO
はじめに おばんです、今年のiOSDCは去年とは打って変わって緊張がハンパない田中です。お腹が痛い...、ｳｯ...！ 2017/09/15 - 17で開催される iOSDC 2017 というカンファレンスで登壇させていただきました！このエントリは当日喋った内容を、登壇者ノートを添えて、抜粋して紹介します！ 登壇後すぐアップしていますので、質問がある方などが参照しやすいようになれば幸いです。 トゥギャっていただきました。 まとめ・感想 解説が長いのでまとめを先に記述します。 だいぶ抽象的に喋りました。きっと無限のマサカリが飛んでくるかとは思いますが、スライドや発表を補填する議論は大歓迎なので、なにかありましたらTwitter(@ktanaka117)にメンション飛ばしてください！ 貴重な発表の機会をいただき、ありがとうございました！ 発表内容 以下解説。 例えばこれ。ライフサイクルの中にベ
階層アーキテクチャの利点は、複雑さの減少 ― ＠IT
個々のコンポーネントを組み上げて、どのようなシステムを構築するか。構造（アーキテクチャ）によって、できあがるシステムの性質が変わってくる。作り手側の視点に立てば、どのようなアーキテクチャを採用するかによって、作り方も変わってくる。いままで連載した記事を通して、わたしたちは、個々のコンポーネントの作り方を学んできた。今回からは、コンポーネントをいかに組み上げるか、という課題に知恵を絞ることになる。コンポーネントの利点を最大限に生かすこと。それがアーキテクチャ設計の現実的な意味の1つだ。そして、1つの有効なアプローチに階層化アーキテクチャがある。 前回「使いやすくて、変化に強いコンポーネント」までにサブシステムなどを利用したコンポーネントの作り方についてお話ししてきました。それでは、コンポーネントは実際どのような単位で作り上げていけばよいのでしょうか。 コンポーネントの単位として考えられるのは
使いやすくて、変化に強いコンポーネント
前回「コンポーネント化でクラスをすっきり整理」は、パッケージとサブシステムによるコンポーネント化についてお話ししました。コンポーネントとは、どのように考えて作り上げていくのでしょうか。単純に似たようなクラスをまとめるだけでは、使いやすいコンポーネントにはならないでしょう。今回は使いやすく、保守しやすいコンポーネントを作るにはどのような考え方で設計するのかについてお話ししていきます。 コンポーネントとは 最初に、コンポーネント（部品）とはどのようなものか考えてみましょう。 自作パソコンを作ることを考えてみます。パソコンは電源ユニット、CPU、マザーボード、ビデオカード、メモリなどの部品から構成されています。製作者は、どのようなパソコンを作りたいかを考え、目的に合った部品を選択します。次に、それらの部品のインターフェイスを調べ、お互いのインターフェイスが合っているかを調べます。そして、実際に部
ビジネスロジック - Wikipedia
ビジネスロジック（英: business logic）は、データベース上のデータに対する処理手順といったようなものを指す、ソフトウェア工学的な用語である。「アルゴリズム」という語が説明に使われていることがあるが、アルゴリズムは数学的・論理的に明確な概念であり間違った説明の仕方である。基本的には、エンタープライズ系（業務支援系）ソフトウェアを開発する企業が内部的に、もしくは顧客への販売促進のために用いる用語である。この用語は、主にプログラムが3層構造となるWebアプリケーション開発で使われる。ビジネスロジックは3層の中の中間層（アプリケーションサーバ）に相当する。いずれにしても、ビジネスロジックという用語は明確な定義がなく、人によって意味が異なる可能性がある。 ビジネスロジックの範囲[編集] 実世界のビジネスオブジェクト（勘定、貸付金、旅程表、在庫目録などなど）をモデル化したもの そのような
ビジネスロジックとは
Landscape トップページ | < 前の日 2005-12-11 2005-12-12 次の日 2005-12-13 > Landscape - エンジニアのメモ 2005-12-12 ビジネスロジックとは 当サイト内を Google 検索できます * ビジネスロジックとはこの記事の直リンクURL: Permlink | この記事が属するカテゴリ: [プログラミング] 私はビジネスロジックを「アプリケーションがおこなう処理やルール、その手順」という意味で使っている。 ビジネスロジックという言葉を使うようになったのは、いつからだろう。私の周りで会話で普通に使われるようになったのは、3年から4年前くらいだろうか。書籍やウェブではもっと前から当たり前に使われてたんだろうけどね。 コンピュータ系の用語は、使う人によって意味が異なったり別の物を指していることがよくある。私の中の「ビジネスロジッ
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
こんにちは。 EC-CUBE運営チームの高橋です。 EC-CUBEがver.3になるため、その情報発信・共有の場として、Qiitaを使わせていただくこととなりました。 よろしくお願い致しますm(_ _)m さて、表題についてです。 EC-CUBEが目指すものを実現するためにビジネスと技術の両方から考えた上での、Silex採用です。 EC-CUBE3の目的 EC-CUBEをECサイトだけでなく、ECアプリケーションのプラットフォームへ進化させる ユーザ層の拡張 そのために実現したい技術 プラグイン競合の解消 WebAPIの実装 コアアップデートの提供 UIの刷新 モダンなPHP開発手法 以上の観点で、社内外含め議論を重ねた上で、EC-CUBE3では、これまでの独自実装も活かしつつ「FWの採用」を決めました。 しかし、PHPのFWは、現在数多く存在します。 では、なぜ、その中でSilexを選ん
IT・システムのトレンドは常に変化していっています。特に最近はではIoTに代表されるように、場所・モノを問わず システムにアクセスできる事が多く求められます。そうしたトレンドにおいて、Domino・XPagesでどのように対応するべきか、 技術者として何を目指すべきなのか、といったことなどをお話します。 Read less
アイデア元 Web アプリの MVC 設計まとめ - もやし日記 概要 上記のリンク先の目次がそのまま解決したい課題となっています。以下に抜粋します。 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく？ これを CakePHP で解決する方法を検討します。 解決案 - Logic モデルを作成する ※ 2015-05-12 追記 Logic コンポーネントの方がよいのでは、という議論もコメント欄でしていますので、合わせて参照下さい。 ※ 2016-07-21 追記 下記記事にある 「Service層」のことをやりたい、という話でした。 Webアプリケーションの構成に関する予備知識 http://qiita.com/okeyaki/items/37eb4b66bd8ef62c1fe8 検討といいつつ自分が実践して
JavaとOracleを使って業務システムを開発しています。 ビジネスロジックをどこに持ってくるか悩んでいます。 ストアドプロシージャにビジネスロジックを実装した方がパフォーマンスもよくなると思うのですが、社内的には反対意見も多いです。 ストアドプロシージャにビジネスロジックことがある方、検討したことがある方、利点や弊害など教えてください。 逆にJava側に乗せた方がよいという方も、ご意見頂戴できればありがたいです。
2008-05-19
んー、マーケットどころか社員からも受け入れられてないなんて・・・・・ http://www.infoq.com/jp/news/2008/05/sun-deflextions-continue 業務システムにOOはほとんど必要ないと考えている断然トランザクションスクリプト派の わたしですがｗ、下記の説明をみても従来のトランザクションスクリプトとの違いがそんなにない気がする。 DDDのServiceパターンはエンティティとして扱えないものだけを どのように一貫して抽出するのかというのがポイントになりそうだけど、 どの時点で扱えないと判断するのかが明確じゃないように思うので、抽出基準が きちんと定まらず使いにくいんじゃないすかね。 というわけで、おいらは過去から一貫して、トランザクションスクリプト派で、 かつレイヤ的には Pageモデルを使うならば、Page（副次的にActionが入る余地あり
Javaプログラムをこれから始める方に向けて、毎回一つの要素を深堀りしながらJavaプログラムの書き方を学んでいただけます。 このコースでは、JavaのWebアプリケーション技術であるJava EEの要素を学びながら、全14限でショッピング風サイトの作成を目指します。 14限目はこれまでショッピング風サイト作成の後半として、ビジネスロジックの作成と動作確認を行います。 ※事前にMySQL入門コースを受講していると、理解度がより深まります ■ アジェンダ ・進捗状況と今回作成分を確認する ・Servlet、DAOを作成する ・Webアプリケーションの動作を確認する ■事前準備 この授業は「Java入門（全3回）」 https://schoo.jp/course/280 及び「Java入門 -計算機プログラムを作りながら学ぶJavaの基本-（全10回）」https://schoo.jp/cou
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webアプリをあっという間にカッコよく！ BootstrapによるレスポンシブWebレイアウト
「ビジネスロジック」とは何か、どう実装するのか - Qiita
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
DDDで設計するならCQRSの利用を検討すべき - Qiita
3層アーキテクチャで最も謎な「ビジネスロジック層」 “システムのコア”をゲーム「リバーシ」で解説
[DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita
「ビジネスロジックの処理は2つに分類すると整理しやすい」 4つの例から考える、プレゼンテーション層・データアクセス層の見分け方
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
なぜ、EC-CUBEはSilexを採用したのか - Qiita
IBM Dominoとモダンアーキテクチャ
肥大化するコントローラを避ける (CakePHP 編) - Qiita
JavaとOracleを使って業務システムを開発しています。…
Java入門 -ショッピング風サイトの作成②-｜オンライン動画授業・講座のSchoo（スクー）