【C#】ValueObject作成時のGetHashCode()のオーバーライドの実装方法 - Qiita
前提知識(知っている方はスキップ推奨) そもそもValueObjectって何？ ざっくりいうと、システム固有のオブジェクト(独自型)です。 値が持つビジネスルールを表現することができます。 詳しくはググってみてください。 そもそもハッシュ関数って何？ 入力されたデータを"何らかの値"にして返却する関数です。 "何らかの値"を生成するときは、ある一定のルールに従って行われます。 したがって、同じ値をハッシュ関数に与えると、同じ値が返却されます。 尚、ハッシュ関数が返却する値をハッシュ値と言います。 ValueObjectが単一の値しか持たない場合 プロパティに対してGetHashCode()をするだけでOKです。 public class Id { public int Value { get; set;} // ...略 public override int GetHashCode()
MVVMのModelにまつわる誤解 - the sea of fertility
こちらに移転してきて初めての記事です。 最近たまに話題になるので書いておきます。MVVMのModelについて誤解されやすい部分のお話です。最近よく議論してるasync/awaitの話とは関係がありません。なおこの話は以下のスライドを理解している事が前提となります。 共有したい理解(ゴール) ViewModelはModelの影 ModelについてViewModelが行うことは、イベントに対する反応と戻り値のないメソッドの呼び出ししかない事 これについての理解を共有できるよう説明していきます。 VIewModelはModelの影 スライドにもしつこく書きましたが、MV○(MVVMやMVC/MVP)のModelは大変分厚くなるし、アプリケーション間で使いまわすことなんてできません。ModelはUIを意識しない？？いや、何度も言っていますが、意識はする必要があるんです。ただUI実装の知識が必要ない
DDDの腐敗防止層を用いた変更容易性向上 - READYFOR Tech Blog
こんにちは、リファクタリング大好きなミノ駆動です。 リファクタリングを主任務とするアプリケーションアーキテクトとして、弊社READYFORのエンジニアリングを推進しています。 ドメイン駆動設計に登場する 腐敗防止層 を用いたリファクタリングで、システムの変更容易性を向上したお話を解説します。 本記事の概要 イビツな構造を隔離する腐敗防止層を用いて技術的負債を解消 ふたつの橋作戦でリファクタリングの安全性を向上 設計技術書 『良いコード/悪いコードで学ぶ設計入門』 出版のお知らせ 背景 弊社READYFORのシステムは、モノリシックなRuby on Railsのサービスとして実装されています。 システムが解決したいドメイン（業務活動）にはさまざまなセグメントがあり、その中に審査オペレーションがあります。 審査オペレーションとは、クラウドファンディング実行者さんが申し込みを提出してからプロジェ
DDD基礎解説：エンティティ、値オブジェクトってなんなんだ - little hands' lab
はじめに DDDの実装パターンとして、エンティティと値オブジェクトというものがあります。 ドメイン駆動一般に複雑な抽象論が多い中で、コードに近く一番イメージがつきやすいコード事例として出てくるため、ここだけは何となくわかるぞ！という方もいらっしゃるのではないでしょうか。 今日はこちらの概要とそれぞれの使い道について書きたいと思います。 先にざっくりイメージ図をお伝えすると、こういう図を使って解説します。 何の目的で作るのか？ ドメイン駆動設計は何を解決しようとしているのか こちらの記事で、ドメイン駆動設計のアプローチは以下の2ステップがあるということを書きました。 ドメインの問題を解決するための抽象的なモデルを作る. モデルをソフトウェア(コード)に落とし込む ※ ドメイン＝ソフトウェアを適用して問題解決しようとする領域 DDDでは、このStep2の モデルをコードで表現するためのパターン
クリーンアーキテクチャなんもわからんからサンプルを実装してみた - Qiita
この記事について クリーンアーキテクチャについて本(Clean Architecture 達人に学ぶソフトウェアの構造と設計)を読んだのですが、本を読むだけだと実感が湧かない部分がありました。 そういうときは実践してみるに限る！ということで自分でサンプルを実装してみました。 私は組み込み系の開発者なので、デバイス制御するWindowsアプリケーション(C#)を作ってみました。 実装の対象 サンプルとして、外部(テストツール)からTCP/IPでコマンドを受け取って、仮想デバイスを制御するようなWindowsアプリケーションを作成しました。 持っている機能としてはこんな感じです。 モーター移動コマンドを受け取ったら指定された分だけモーターを動かし、これまでの合計移動距離を画面に表示する センサー読み取りコマンドを受け取ったらセンサーの値を拾って画面に表示する ※実デバイス制御は行いません。デバ
ドメイン知識が漏れるとは何なのか
こんにちは。株式会社プラハCEOの松原です 先日プラハチャレンジのメンターセッションで「ドメイン知識が漏れるってどういうことなの？」という話になったので、その際に話したことをまとめてみようと思いました。 こちら本日のメイン、ドメイン知識が漏れまくっているコードです： class Person { // (ドメイン) public age: number public constructor(age: number) { this.age = age } } class Usecase1 { // （アプリケーションサービス層に属するクラス。コントローラー層のメソッドの1つと捉えていただいてもOKです） do(p: Person) { if (p.age > 18) { // 18歳以上なら登録できる！ } } } class Usecase2 { // （アプリケーションサービス層に属する
100日間かけてエヴァンス本を完読しました（PDF公開） - そこに仁義はあるのか(仮)
11/25から3/4の100日間かけてエリック・エヴァンスのドメイン駆動設計を完読しました！ ソフトウェア開発の複雑さに立ち向かうための方法に「ドメイン駆動設計」があります。 エリック・エヴァンスのドメイン駆動設計（以降、エヴァンス本）は発売から20年・日本語訳発売から10年経っても読まれていて、ドメイン駆動設計の原著であり、多くのエンジニアが名著という一冊です。 その分厚さや内容が難しそうというイメージからずっと積んだままになっていている人も多いのではないでしょうか。 エリック・エヴァンスのドメイン駆動設計 作者:Eric Evans翔泳社Amazon 私もそんな一人で、ドメイン駆動設計をなんとなく知った風に過ごしていましたが、ドメイン駆動設計に関する勉強会への参加をきっかけにエヴァンス本と向き合い、知ったこと・学んだことを毎日1ページにまとめてツイートする活動を始めました。 100日間
最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita
TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一本槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる「イベントストーミング」がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で「結構日本でやられている取り組みとちがうなー」と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守（あるいは鹿鳴館精神）ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基本線となりつつある、、、のか？ まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも「ドメインイベント」として実装パタ
RestAPIをCleanArchitectureで実装する際のreq/resの持ち回りについて - Qiita
※zennに投稿した記事の転載です。 概要 提題の通り、CleanArchitectureに則ってRestAPIを実装する場合に、 以下の2点に迷ったので、結論とそれに至るまでの考えを書き残しています。 requestオブジェクトはどのレイヤーまで持ち回すべきか？ responseオブジェクトはどのレイヤーで生成するべきか？ 背景 よくあるシンプルなCRUDアプリを実装する際、以下のような処理を実装するとします。 この場合、controller→usecase→repositoryとMVCやレイヤーアーキテクチャ的にパッケージを掘っていき処理を実現して行くのは誰もが違和感なく考えられることですが、 今回はCleanArchtectureを採用しているため、controller → usecase ← repositoryのような依存関係で実装する必要があります。 ※詳しくは後述するClea
とにかくドメイン駆動設計を実践してみる試み ～TODO管理システム編～
はじめに この記事はサービスを爆速で作ったり、ドメイン駆動設計の解説をするようなものではありません。 ドメイン駆動設計の勉強をしていて、手を動かす機会が足りないと感じていました。そこで、今の理解で実際に動くシステムをドメイン駆動で開発してみようと思いました。 本記事はその開発の過程や考えていたことを記録したものです。 「この人はこういう形に落とし込んだんだな～」くらいで見ていただけたらありがたいです。 作成するシステム 今回作るのはTODO管理システムです。 初回の開発では以下の機能を開発しました。 TODOのタイトルと詳細を登録できる 作成したTODOを検索できる 選択したTODOの詳細を確認、完了、削除ができる デモ デモなのでメールの確認はダミーです。新規登録をしたら画面に出るメール確認リンクを踏めば確認済みとなります。 その後右上のログインからログインしてください。 デモのデータベ
DDD 指向マイクロサービスの設計 - .NET
このコンテンツは eBook の「コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャ」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。 ドメイン駆動設計 (DDD) は、ユーザーのユース ケースに則したビジネスの現状に基づくモデリングを提唱します。 アプリケーションの構築のコンテキストで、DDD は問題をドメインと呼んで論じます。 独立した問題領域のことを境界付けられたコンテキストと言い (境界コンテキストはそれぞれ特定のマイクロサービスに関連します)、共通の言語を使ってこれらの問題を論じることを重視します。 また、内部実装をサポートするための多くの技術的概念とパターンも提案します。たとえば、(ドメイン モデル貧血症ではなく) 豊富なモデルを持つドメイン エンティティ、値オブジェ
DDDにおける認証の実装場所
こんにちは。株式会社プラハCEOの松原です。 DDDに基づいて開発しているアプリケーションの「認証」ってどこで実装するのが良いのだろう？ 対象読者 何となくDDDに関する本を読んで理解した気がする 試しにDDDに基づいてアプリケーションを実装し始めた 認証の実装をどこに書くべきかわからず詰まった 結論（オニオンアーキテクチャの場合） 実装はUI層かInfrastructure層 自分ならInfrastructure層 認証後のインターフェースはアプリケーション層 コンテキストは1つにまとめている前提（認証コンテキストを作らない場合の置き場所） UI層って何やねん DDDとの相性の良さからよく併用されるオニオンアーキテクチャの図を見ると、以下3つの層が一番外側に位置しています： UI(User Interface) Infrastructure Tests (図はこちらから引用) UIと言え
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/
![ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c7728c664ddd298cabc00615869a23f196ad5f90/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F2022-220117111455-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
ドメイン知識を隠すコード、隠さないコード - Magnolia Tech
2021/12/20追記 指摘されて気づいてしまいましたが、間違ってますね... 以前スライドを書いた時に全然気づいていませんでした 反省のために消さずに、取り消して残しておきます 「年齢計算ニ関スル法律」という法律がある。 明治三十五年法律第五十号（年齢計算ニ関スル法律） | e-Gov法令検索 とても短い法律で条文は3つしかない。 ① 年齢ハ出生ノ日ヨリ之ヲ起算ス ② 民法第百四十三条ノ規定ハ年齢ノ計算ニ之ヲ準用ス ③ 明治六年第三十六号布告ハ之ヲ廃止ス ポイントは①で、生まれた日から起算するので法律上は1年が経過した時に1つ歳を取ることになる。つまり、誕生日の前の日の24時に年齢が加算されるので、日単位でみると誕生日の前の日にもう年齢は進んでいる、ということになる。 同じ年の4月2日生まれの人と、4月1日生まれの人とでは小学校に入学する年度が違う、というのはよく聞く話だと思う。 この
ドメイン駆動設計のリポジトリに対する考察 - Qiita
この記事は ZOZO #4 Advent Calendar 2021 １3日目の記事になります。 今回はエリック・エヴァンスのドメイン駆動設計(以下、DDD本)、実践ドメイン駆動設計(以下、IDDD本)を読み比べ、リポジトリの設計について考えたことを書いてみようかと思います。 そもそもリポジトリとは何か？ そのまま翻訳すれば、「倉庫、金庫、倉」。ドメイン駆動設計的には、集約のインスタンスを永続化しておくところと言えるでしょう。 DDD本を読むともう少し深い意味を見いだせます。 そもそもリポジトリの章は「第６章 ドメインオブジェクトのライフサイクル」の中にあり、ドメインの生成から削除される過程までのライフサイクルに関わる機能であることがわかります。 クエリを実行して、属性に基づいてデータベース内でオブジェクトを見つけるか、もしくは、オブジェクトの構成要素を見つけて、それを再構成するというもの
クリーンアーキわからんかった人のためのクリーンじゃないけどクリーンみたいなオニオンに見せかけたSOLIDの話
依存関係逆転則含む諸原則に苦しめられた方々，いかがお過ごしでしょうか． 今回はアプリ設計の話です．と言っても，前回「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」というZenn記事を書いて，反響が大きかったのでリメイクしたいなという気持ちになり執筆することにしました． 前回同様，調べていく上で誤解していた部分や理解しにくかった部分を語った上で，オニオンアーキテクチャという，クリーンじゃないけどクリーンみたいな玉ねぎについて紹介するのですが，今回はわかりやすい図解であったり，実際にどのような実装をしていくべきなのかを話の話題として加えていければ良いかな？って思っています． これは前回の記事である「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」の記事の裏話的な話を一つさせてください． 今年の11月初め頃に，サポーターズという企業の学生が登壇できるLT会があり，私
DDDを実践するための手引き（概論・導入編）
ナニコレ DDDは「Domain-Driven Design（ドメイン駆動設計）」の略語で、エリック・エヴァンスさんという人が考えるソフトウェア設計におけるプラクティスまとめみたいなものです。 『エリック・エヴァンスのドメイン駆動設計』というバイブル的な書籍がありますが、「途中で挫折した」「読んでもよくわからない」「よくわからないけど自分なりに解釈して実践している」というような感想をよく聞きます[1]。DDDの概念は幅広く、哲学的で、抽象的であるため、DDDをどのように解釈しどのように実践すればいいのかわかりにくいものです。 この記事ではそのような問題に悩んでいる人たちのために、数年に渡りDDD（的なもの）を実践してきた筆者が噛み砕いた（個人の独断的な）解釈と実践方法を解説します。 DDDってなぁに？ DDDがカバーする領域 DDDが言及する範囲はとても幅広いです。エリック・エヴァンスさん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: DESIGNING CONNECTED CONTENT デジタルプロダクトの長期的な成長を支える構造化コンテンツ: マイク・アザートン (著), キャリー・ヘイン (著), 石橋秀仁 (監修), 斉藤美絵 (編集), 佐藤英一 (編集), 岡本淳 (編集), 株式会社Bスプラウト (翻訳): 本
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.