CQRS実践入門 [ドメイン駆動設計] - little hands' lab
この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事
![CQRS実践入門 [ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/c1461d1de08cfc1309c0a0f3c18a2f498485bb45/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F1a101957924fd716c353278f0d65759b39326613%2Fbackend%3Dimagemagick%3Bheight%3D1200%3Bversion%3D1%3Bwidth%3D1200%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20191202%252F20191202061944.png)
アジャイル迷子のための「アジャイルの本質」。あとDDDとのつながり - little hands' lab
記事の構成 アジャイルソフトウェア開発とは アジャイルマニフェストとは アジャイルマニフェストの問題 そこで、アジャイルの本質 by マーティンファウラー アジャイルソフトウェア開発とは？ アジャイルソフトウェア開発とはなんでしょうか？ 「アジャイルマニフェスト(後述)の4つの価値観、12の原則に従う開発方法の総称」 これが最もオリジナルな定義です。 なぜこんなややこしい言い回しをするのは後から説明します。 重要なことは、「アジャイル」という具体的な手法があるわけではないということです。 アジャイルはマインドセット(思想、考え方)です。そのため、 ✖️ do agile 「アジャイルをやる」はありません。 ⭕️ be agile 「アジャイルになる、アジャイルの思想に則る」はあります。 アジャイルの思想に則った開発手法として ・スクラム ・エクストリームプログラミング(XP) ・リーンスタ
設計/コードレビューで"常に"心がけるポイント - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの？」 という
![新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/a20b46277acec6143de80e6f871b31d10bb37865/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F8e08ff0ada048e7c9664cc1d0ae9f2adc0bd4b93%2Fbackend%3Dimagemagick%3Bheight%3D1300%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20181210%252F20181210195849.png)
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab
DDD連載記事 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっつきやすい」と考えるアーキテクチャを紹介します。 前提としてですが、完全に個人的な経験に基づく私見になります。 DDDの理論の中で、アーキテクチャに関しては「エリック・エヴァンスのドメイン駆動開発」(以下原典)と実践ドメイン駆動開発(以下IDDD)とでも異なったものが紹介されており、唯一の正解
![ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/98e9b5a157e996b99fb4d88308422b0a521c0937/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F8d3e611e6f96c01d6ea2f23e2d2a794301f2db7b%2Fbackend%3Dimagemagick%3Bheight%3D1300%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fqiita-image-store.s3.amazonaws.com%252F0%252F30489%252F81fcfd95-2ce1-82a8-db69-8618338a5f22.png)
ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性
![ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/468995f3b9ed8114c64ac798322572db942591ca/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20201221%2F20201221103037.png)
ドメイン知識とユースケースの違いは何か？[ドメイン駆動設計][DDD] - little hands' lab
DDDの文脈の中で、 「ドメイン知識とユースケース(≒アプリケーションの知識)は何が違うのか？」 という疑問がよく持たれます。 この記事ではその違いを説明し、DDDのコードにどう反映するかを書きます。 あるToDoアプリの仕様 事例として、ToDoアプリの話をします。 「仕様を決める」と言ったとき、以下のように箇条書きで決めることがあると思います。(Jiraのようなチケット管理システムのチケット詳細として書いたりしますよね) ユーザー登録、非活性化ができる メールアドレスは重複登録できない タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる タスクは3回までしか延期ができない 非活性化されていないユーザーにアサインができる タスクを完了、アサインするとタスクレポートが作成される これはいわゆる「ビジネスロジック」と呼ばれて、3層レイヤーのアーキテクチャではBusine
![ドメイン知識とユースケースの違いは何か？[ドメイン駆動設計][DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/0875f8b3178c00cab1fef1b61aa8b0ce19d6e550/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F1e681bbb59c1d58f3d7c4c14af30922252cdc250%2Fbackend%3Dimagemagick%3Bheight%3D1300%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20190726%252F20190726071431.png)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
