集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話 - kbigwheelのプログラミング・ソフトウェア技術系ブログ
本記事はドメイン駆動設計 Advent Calendar 2018 - Qiitaの3日目の記事です。 2日目は、grimroseさんのぐるぐるDDDで気をつけてることでした。 4日目は、s_edwardさんのMicroservices と DDDです。 Table of Contents Table of Contents 以下の記事を読むにあたり前提となる知識 問題 サービス詳細 ユビキタス言語 重要なビジネスルール モデリング 上の何が問題？ 解決策 解決策1 集約をマージする 解決策2 一時的な整合性の破綻を受け入れ結果整合性を使う 解決策3 アンチパターンではあるが集約間の整合性維持のためトランザクション制御を用いる 解決策4 ユースケースの見直しによる再モデリング まとめ とりあえず今どうやっているか 最終的にどうするべきだと考えているか(2018/12/01時点) ソリューシ
InfoQ: ドメイン駆動設計・開発の実践
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
ドメイン駆動設計入門 - Digital Romanticism
"Beautiful Develpment"（10/27 DevLOVE）の講演資料と原稿 はじめに 本日（10/27）、DevLOVE様主催で、"Beautiful Develoment"と題されたイベントが開催されました。これは「ドメイン駆動設計（"DDD:Domain-Driven Design"）」を題材に、入門から実践までを語り尽くすというコンセプトのものです。このイベントにおける講演のトップバッターとして、ドメイン駆動設計の根底にある基本的な考え方についてお話しさせて頂きましたので、講演資料と原稿を公開いたします*1。 スライドはこちら アジェンダは以下の通りです。 導入 オブジェクトとは？ モデルとは？ ドメイン駆動設計とは？ まずは、ドメイン駆動設計のベースとなっている、「オブジェクト指向」や「モデル」について整理した上で、実際にドメイン駆動設計とはどういうものかを見ていき
ドメイン駆動設計・基盤編 - Strategic Choice
書籍「エリック・エヴァンスのドメイン駆動設計」の「第１部 ドメインモデルを機能させる」をまとめます。まず「ドメイン駆動設計」そのものを概観して、その後、「ドメイン駆動設計」の基盤となる３パターンをまとめます。目次ドメイン駆動設計（DDD：Domain Driven Design）の「Overview」 ドメイン駆動設計の「What」ドメイン駆動設計の「Why」ドメイン駆動設計の「How」ドメイン駆動設計の基盤となるパターン ユビキタス言語（UBIQUITOUS LANGUAGE）モデル駆動設計（MODEL-DRIVEN DESIGN）実践的モデラ（HANDS ON MODELERS）出典エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 20
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
