Flyweight DDD 軽量DDDを避けつつ軽量(Flyweight)にDDDを導入するためのアーキテクチャです。
![DDD導入に踏み切れない方へ贈る「2層 + CQS アーキテクチャ(Flyweight DDD)」/Flyweight DDD](https://cdn-ak-scissors.b.st-hatena.com/image/square/d4cf5bc8ad632edb2b79cb736645dea2a95ae6f4/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F13426cb7b1974a8aa3beaf132dbf50f5%2Fslide_0.jpg%3F13530818)
はじめに タイトルの表現が適切か自信無い。 TypeScriptを使い始めて、早数ヶ月なんとなく感覚を掴んできた。(気がする) 最近AWS Lambdaを扱うことが多く、もちろん実行環境はNode.js(JavaScript)を選択しています。 そんな中色々どう作っていこうかと考えていった中で、特にDynamoDBの操作は書いていくと、大体同じ書き方になるし何よりテストを書くのがめんどくさい。 こういうのはアプリケーションから分離して汎用化(外部モジュール化)してしまいたい。 本投稿では汎用化することを目的とし、以下を参考に TypeScript で型定義の恩恵を得つつ、どう作成したのかを書きます。 [ 技術講座 ] Domain-Driven Designのエッセンス -目次-|オブジェクトの広場 DDDについて 参考 ドメイン駆動設計の用語と解説(抜粋版) - Qiita ドメイン層を
1年前くらいにRailsの設計にDDD(ドメイン駆動設計)のService層を導入し、Modelの肥大化対策をしました。 この記事では、まずどのようなルールでService層が組み込まれているかと、1年間運用してみて良かったところ、悪かったところの感想を書きます。 [2018/05追記] 最近ではサービス層の導入は賛否両論あるようなので、導入する際は自分のプロジェクトに合っているかどうかを十分にご検討ください! Service層を導入するきっかけになった問題点 Modelの肥大化 Model間の複雑な依存関係 多数のミドルウェアの導入による複雑さの倍増 これらにより.. メンテナンスやテストがしにくい コードが整理されていないのでとにかく読みづらい Model複雑化の例 <ユーザがECサイトの商品をお気に入り(like)にするメソッドを書く場合> 処理に関連するテーブル my_itemsテ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く