はじめに React でコードを書いているとき、ある程度の規模のプロジェクトになると class を使いたくなりませんか？ 僕はバックエンドで DDD を用いている場合は、同じように Entity を宣言して使いたい場面が多々ありました。 しかし、React のプロジェクトで getter/setter を用いて値を変更しても残念ながら再描画はされません。 Redux の処理内や hooks 内で中途半端に class を用いても結局 DDD の設計思想をうまくコードに落とし込むのは難しいです...（どなたがご享受ください！） 今回は僕が Recoil を使ってフロントエンド DDD を手軽に実装する方法を共有したいと思います。 また、まだあまり技術記事で紹介されていないTypescriptでのサンプルコードやatomFamily, selectorFamilyの紹介も多く含んでいるので参
【C91新刊（電子書籍）】 わかる！ ドメイン駆動設計～もちこちゃんの大冒険～（A5相当で60p）はソフトウェア設計手法であるドメイン駆動設計（DDD）の解説書です。 DDDの原書である「エリック・エヴァンスのドメイン駆動設計」はたいへん分厚く、読み応えがある内容です。 そこでDDDを理解する手助けに（すべてを解説するのではなく）入門に必要な知識をわかりやすく、物語を通じて理解できる構成にしました。 主人公の「もちこちゃん」はモバイルエンジニアであり、いろんな人の手を借りながらソフトウェアモデルを設計していきます。道中にもちこちゃんが出会った問題は、どんなエンジニアでも遭遇する共通の課題です。本書を読むことでチームでの開発指針を定めたい、プロジェクトの見通しを良くしたいなど複雑化したソフトウェア開発を良くしていく活動への示唆となれば幸いです。 もちこちゃんの冒険が今から始まる。 【電子書籍
ドメイン駆動設計の考え方は書籍を読むとわかりますが、いざモデリングを実践しようとすると、どこから手を付けていいかわからない、ドメインモデリングの始め方がよくわからないという意見を聞きます。 このスライド資料では、そんな悩みを持つ皆さんに向けて「ドメインモデルを見つけ出し・実装に落とし・改善していく」方…
このエントリは Ruby on Rails Advent Calendar 2014 の 7 日目のエントリです。 前日は seri_k さんの「Turbolinksさんと上手く付き合う10の方法」でした。 お詫び WIP です。公開期限に間に合わない可能性があるため、まだ途中ですが先に公開してしまいました。 サンプルコード等を後ほど追記する予定です。 → 12/08 18:10 追記しました。 Rails のファットモデル問題 Rails で構築したアプリケーションが大規模になり機能が増えていくにつれてモデルが大きくなり、そのうち手がつけられなくなる問題は古くから指摘されています。これについてはもはや詳細を述べるまでもないと思うので割愛しますが、この問題は 2014 年になった今でも多くの開発チームを悩ませていると感じています*1。 このエントリでは、普段 Rails を業務で使いながら
ドメイン駆動設計との出会い １０年前に、エヴァンスのドメイン駆動設計を初めて読んだ時は、書いてある内容がほとんど理解できなかった。 あまり、面白いとも思わなかった。 当時は、現場でバグだらけのコードと格闘していた。障害が報告されるたびに、リファクタリング本を参考に、該当個所の長いメソッドや大きなクラスを片端からリファクタリング。その結果、コードがわかりやすくなり、やっかいなバグが単純な修正で解消できてしまうことの効果に驚き、設計の重要性を再認識していた。 それ以前は、UNIXとC言語、OracleとPL/SQLという、オブジェクト指向ではない世界で技術を身に着けてきた。 どちらかというとオブジェクト指向には、ネガティブな印象を持っていた。現場では役に立たんだろうと。 バグとの格闘の中で、リファクタリング（設計改善）の威力を肌で感じ、その考え方とやり方がオブジェクト指向に由来するということを
JavaScriptでは、最近、DOMContentLoadedをよく目にします。 原典 ###クリーンアーキテクチャ(The Clean Architecture翻訳) JavaScriptで実践 勤務実績一覧 人を選んだら過去勤務実績を年度/毎月(概要あり)のタブ区切りで表示する 毎月、何時間働いたか、その内訳は何か 選択ユースケース 選択した所属部門に属する人だけ絞込可能 選択可能な従業員の勤務形態も同時変更 さらに選択した勤務形態(社員/パート)でも絞込可能 この場合は所属部門は絞り込まれない 同様に、勤務した個別月から絞込可能 UIイメージ 早速困ったこと Usecaseの粒度 ひとまず、class Usecaseで一つ FilterUsecase#changeDepartment(i, department) FilterUsecase#changeLabortype(i, l
はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: 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/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は
流行りの monorepo 風味と DDD 風味？ 今回はコードの設計について書き残します。主に JavaScript 界の話です。Web アプリケーション全体の設計は次回で、今回はコード面の設計に限定して書き留めています。プロダクト全体のアーキテクチャは次の記事で述べる予定ですが大雑把には、メディアっぽいサービスでありつつも SPA + SSR が許容される程度には要件定義の時点でコードの行数がかさむことが約束されたプロダクトです。 今回は大きく分けて下記について述べています ディレクトリ構造 オブジェクトの種類と責務 Flux 的なデータフロー あくまで風味なので今回、専門用語の意味ズレなどは優しくお願いします... このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と web
Webにかぎらず、アプリケーションというのは作って終わりではなく、その後も継続して改修・改善されていくケースが多い。受託で開発して納品して終わりというケースでも、納品した先にメンテナンスする人がいる。 この記事では、Angularアプリケーションの開発において、いかにメンテナンス性を維持して、持続可能なプロジェクトを構成するかについての個人的な見解をまとめる。 フレームワークを邪魔しない Angularアプリケーションのメンテナンスにおいて、いちばん重要なことはいかにAngularのアップデートを阻害しないかという点に尽きる。 これはAngularに限った話ではなくフレームワークと呼ばれるものを使うなら常に必要なことであるし、 アップデートが定期的に降ってくることが決まっているAngularであればなおさらである。 アプリケーションの一番根幹となる部分の鮮度が落ちれば、その他の部分はそれに
speakerdeck.com 第3回Reactive System Meetup in 西新宿のLTで発表をしてきました。 reactive-shinjuku.connpass.com LTという都合上、含めたかったけれど泣く泣く削ったボツネタも併せて補足するエントリです。 （例によって長いです。） Reactive Systemの文脈でドメインイベントを使うモチベーション 今回のLTの募集要項が「リアクティブに関連すればなんでも」なのに、思いっきりDDDの話じゃん！というのが、もしかしたらあるかもしれませんので、ここで補足しておきます。 引用：The Reactive Manifesto 上図の通りMessage Drivenがリアクティブシステムでの基盤となります。 このMessageは大きく3種類あることはスライドで述べましたが、その内のEvent Messageはリアクティブシス
Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa
DroidKaigi 2018のスライドです
READY FOR THE BATTLE? -Introduction to Live Coding-
おつかれさまです。そろそろ、プログラミングに関するエントリも書かなければw DDDの勉強を開始するにあたって、一番最初にEntitiesとValue Objectsに出会う。 今回は、まず先にValue Objectsと関連が深いImmutableについて、考えてみよう。なぜ、Value ObjectsかというとOODの基礎をなすからだ。基礎が弱いとその上の建造物ももろいものとなってしまう。だからValue Objectsがまず先。なーんだ、ただのJavaBeansなんでしょ、と思うと痛い目にあうよw 値を表すのがValue Objects。説明することが目的のオブジェクトである。ここに説明されているとおり。 ● Value Objects（値オブジェクト）パターン エンティティとは逆に、たとえば「色」や「量」のように、その属性だけが重要で、アイデンティティを考えることに意味のないオブジェ
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
A blurb from Vaughn Vernon in Implementing Domain-Driven Design (2013) has a fantastic explanation to what Domain-Driven Design is: The software development approach called Domain-Driven Design, or DDD, exists to help us more readily succeed at achieving high-quality software model designs. When implemented correctly, DDD helps us reach the point where our design is exactly how the software works.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 「実践ドメイン駆動設計」から学ぶDDDの実装入門 CodeZine Digital First: WINGSプロジェクト青木淳夫 (著), 山田祥寛 (読み手): Digital Ebook Purchas
