TL;DR Entityとはシステム化しているしていないに関わらず存在するものという意味としてCAでもDDDでも同じものです。一見違うように見えるのは、CAでは「対象とそれを操作するロジックをEntityにまとめられる」という話に重点を置いているのに対しDDDでは「対象は操作して状態が変わったりValue Objectとかに分割しても同じEntityである」という話に重点を置いている、つまりDDDのが細かい話をしているというだけです。 前置 ドメイン駆動設計のエンティティとクリーンアーキテクチャのエンティティとEntity in DDD ≠ Entity in Clean Architectureを読みました。 非常に勉強になる記事なのですがこの記事の中にもあるようにこの分野では大体あってるけど厳密には違うという言葉があります。逆に、ぱっと見別のものに見えるが厳密には同じものであったりしま

はじめに 最近よくクリーンアーキテクチャが話題になってて、関心が高まってる感じしますよね！ ということでカブク社内でも書籍『クリーンアーキテクチャ』の輪読会が開催されました！ この記事は null 個人の考察です。 クリーンアーキテクチャとは 書籍を読んでみた結果、次のブログ記事がすべてだと言っていいと思いました。 クリーンアーキテクチャ(The Clean Architecture翻訳) | blog.tai2.net https://blog.tai2.net/the_clean_architecture.html 上記ブログ記事に比べて書籍に含まれる文字数は膨大ですが、膨大なのは前提知識（プログラミングパラダイムとか設計原則とか）と歴史と補足（と著者のカタルシス）です。 以下の私の記述は基本的に上記ブログ記事に対する考察と取っていただいても差し支えありません（ただし引用文は書籍からの

この記事は次の記事の続編に近い内容となっています。 もし可能であればこちらの記事を読み進める前に、次の記事をご覧いただくとより内容がわかりやすいでしょう。 Laravelで実践クリーンアーキテクチャ: https://qiita.com/nrslib/items/aa49d10dd2bcb3110f22 はじめに 皆さんこんな図をご存知でしょうか。 The Clean Architecture: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html これはクリーンアーキテクチャというアイデアを表した図です。 同心円が特徴的な図ですね。 この同心円は、最も重要なビジネスロジックを中心に見据えることで外界の変化から防衛、対応していこうというコンセプトを表しています。 より具体的にいえば、ビジネス

この記事を書くにあたって Laravel について色々サポートしてくれた皆さまに向けてお礼申し上げます。ありがとうございました。 本記事はクリーンアーキテクチャに対する理解を深めていただくために、「実践クリーンアーキテクチャ」の内容を Laravel で実装して解説するという内容になっています。 記事のゴールは「クリーンアーキテクチャに対する理解を深めてもらう」というものです。つまり、この実装の形は一例に過ぎません。 はじめに 皆さんクリーンアーキテクチャはご存知でしょうか。 そう、こんな図のアレです。 The Clean Architecture: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html クリーンアーキテクチャといえばこちらの象徴的な図をまずは思い浮かべるでしょう。 この図を

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

※追記しました 2018/11/10 サンプルコードの言語について、この記事で触れなかったものとその理由について 2018/11/11 諸注意補足 2018/11/12 コードフォーマット、タイポ修正 2018/11/13 ポリモーフィズムのサンプルが弱いとの指摘を頂き追記 はじめに この記事はオブジェクト指向プログラミング初学者向けの記事です。 記事の内容はオブジェクト指向プログラミングの入り口までを解説しているつもりです。 またオブジェクト指向分析やオブジェクト指向設計については取り扱いません。 オブジェクト指向についてを完全に理解するにはこの記事だけでは足りないと思いますのでその点ご留意願います。 サンプルコードは C# です。 スライドが元ネタになっていて、以下の url がそのスライドです。 もし興味が湧いたらどうぞ。 https://nrslib.com/oop-slide-1

最近何かと騒がしいクリーンアーキテクチャですが、丁度プロダクトで採用したところだったので折角なので情報共有ということで 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アプリケーション）：

はじめに この記事は続編です。 前編記事: ボトムアップドメイン駆動設計 https://nrslib.com/bottomup-ddd/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 ファクトリ 独自の採番システム ところで UserId は Guid （Globally Unique Identifier）です。 Guid は事実上どこでどのタイミングで生成したとしてもユニークになります。 その性質を利用して User は一意な id をコンストラクタで生成していました。 しかしプロダクトによっては Guid ではなく独自の採番機能を採用したいという事例は往々にしてあります。 そこでデータベースの採番テーブルを利用した独自の採番システムを利用して User オブジェクトをインスタンス化してみましょう。 コンストラクタで SQL を実行して採番していま

はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は

ドメイン駆動設計には興味を持ちつつエリック・エヴァンスのドメイン駆動設計は数年前に積んだまま、という状態で何年か立ってしまったのですが、新しくDDD の本が出ていたので読んでみたところよかったので紹介させていただきます。 ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 本書は、 『エリック・エヴァンスのドメイン駆動設計』（ISBN978-4-7981-2196-3、翔泳社）、 『実践ドメイン駆動設計』（ISBN978-4-7981-3161-0、翔泳社） に感銘を受けた著者が贈る、ドメイン駆動設計の入門書です。 （https://www.shoeisha.co.jp/book/detail/9784798150727 より。） というわけで、ボトムアップで理解出来る章立てで書かれたドメイン駆動設計の入門書です。 個人的には、ドメインモデルの組み立てをどうやればいいのか

はじめに こんにちは。はじめまして。tarokamikazeです。 これは、社内勉強会用に参考資料をまとめたものです。 この資料のゴール DDD専門用語について、どんなワードでググったらいいかわかるようになる DDDを知らない人が、戦術的DDD(軽量DDD)だけでもやってみようかなという気になる 前段; MVCの限界 余談ですが、凝集度・結合度の観点からするとRailsのMVCがどう問題があるかをコラムで紹介しています。MVCそれぞれの責務を図示すると、低凝集・高結合になっていることがわかります。 とにかく、凝集度、凝集度なのです。 pic.twitter.com/fDWv1ERJA1 — 松岡@技術書典8Day2え28 / DDDブログ書いてます (@little_hand_s) February 2, 2020 あえて過激に言うと。 ある程度の複雑度を持ったアプリケーションにおいて、M

clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心

いわゆるGoFの23個のデザインパターン。知っておくに越したことはないが、フレームワーク・ライブラリに溶け込みすぎていて、現代では知らないうちに使ってることになるので、余裕があれば。

ミノ駆動 @MinoDriven 昨日ゲームプログラミングしてる最中 うちの子「パパの書くプログラムってif文すごく少ないね」 僕「よく気が付いたな。同じ動きのコードでも何も考えずに書くとif文だらけで読みにくくなるんだ。if文をあまり書かないよう設計すると皆に喜ばれるぞ」 とインプットしておいた。 2020-02-25 11:48:13