CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
ドメイン駆動設計 #2 Advent Calendar 2018 - Qiita
ドメイン駆動設計 Advent Calendar 2018が全日程埋まったので後追いで追加させていただきました！ No1の作成者とは異なるのですが、そちらの説明文引用させていただきます！ 推奨ハッシュタグ #ドメイン駆動設計 ドメイン駆動設計(DDD)に関するアドベントカレンダー。DDDに関することであればなんでもOK。 「エリックエヴァンスの」としてないので、ドメインを扱う設計手法であればOKです。実践ドメイン駆動設計でも、CQRS(Event Sourcing), クリーンアーキテクチャとかでもよいですが、必ずドメイン駆動設計にどう関係するか書いてくださいね。 あと、議論のきっかけにできればよいと思いますので、入門的なこと・高度なこと・成功したこと・失敗したこと・改善の余地などハードルは下げますので、自由に書いてください。
設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita
/// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>
大失敗した設計、そしてドメイン駆動設計の基本に立ち返る – 福地春喜のブログ
※ 2019年7月27日に追記しました。 この記事の最後に、失敗談の補足を書いた記事へのリンクを追加しました。 システムの一部機能を改修するテーマが現在進行中です。テーマは他の箇所に影響がないくらいに分離できるものです。この大きさが丁度いい。チャンスとばかりにリファクタリングすることにしました。 アプリケーションはそれなりにレイヤー化されています。controllerとserviceとrepositoryがある。よくある３層構造です。何を見直して再設計するのか？それはドメインオブジェクトモデルの構築です。 現状のアプリケーションはビジネスロジックをモデリングしたものとは言えない状態です。自分がやったのだけれど。しかしだからでもあります。なぜこうなったかを振り返り、どのようにできたかを考えます。失敗から学べることもあるはずです。 参照側の層は薄く？本当に？ 開発対象のシステムはある情報の検索
Laravel で Service 層を取り入れるときに検討したいこと - Qiita
この記事について 普段何気なく使っている Service クラス（Service 層）について、書籍を中心にその役割や目的について書かれた資料を読みながら、Laravel 製のウェブアプリケーションに Service 層を取り入れる際の判断材料となるような情報や観点を、提供できればと思います。 以前にも調べたり考えたりしたんですが、そのときは明確な役割や使い方の提案ができなかったので、それの補遺的な位置づけになります。 Laravelでウェブアプリケーションをつくるときのベストプラクティスを探る (9) Service編 - Qiita Service レイヤーとは これ 出典: Martin Fowler's Bliki https://martinfowler.com/eaaCatalog/serviceLayer.html どんなときに Service 層が必要になるか Despit
ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳)
Alistair Cockburn による Hexagonal architecture の翻訳です。PoEAAで言及されていることから、2002年ごろにはすでにC2 Wikiにページがあった模様。似たようなアーキテクチャである クリーンアーキテクチャ も翻訳したので参考にしてください。 この記事は著者から許可を得て公開しています。Thanks to Alistair Cockburn! 目次 パターン: Ports and Adapters (構造に関するパターン) 意図 動機 解決法の本質 構造 サンプルコード ステージ1: FIT アプリ 定数をモックデータベースとして ステージ2: UI アプリ 定数をモックデータベースとして ステージ3: (FITまたはUI) アプリ モックデータベース 応用ノート 左右の非対称性 ユースケースとアプリケーションの境界 ポートはいくつ? 既知の用
[DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほ
![[DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/42611ef8213959e1f4a5deb05dd044d24ad9c0e8/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCREREJTVEJUUzJTgzJTg5JUUzJTgzJUExJUUzJTgyJUE0JUUzJTgzJUIzJUU5JUE3JTg2JUU1JThCJTk1JTIwJTJCJTIwJUUzJTgyJUFBJUUzJTgzJThCJUUzJTgyJUFBJUUzJTgzJUIzJUUzJTgyJUEyJUUzJTgzJUJDJUUzJTgyJUFEJUUzJTgzJTg2JUUzJTgyJUFGJUUzJTgzJTgxJUUzJTgzJUEzJUU2JUE2JTgyJUU3JTk1JUE1JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0yMmI3ODA2OTU0ZGI0NWE1NDg5ZGU2NGVlOTliNDJmNg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbGl0dGxlX2hhbmRfcyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9M2M3NjhmN2VjOTAyM2RiNTMyMGEzMjE4ZDU3NGE0NjY%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D84e0fa46680fd317c0a8f5dbe33e43b2)
俺たちのドメイン駆動設計はこれからだ！
ドメイン駆動設計に取り組んだ事例をもとに以下の点について説明しました。 1. ドメイン駆動設計とは一体何か？ 2. どんなメリットがあるのか？ 3. ドメインモデルについて 4. 設計パターンについて 5. ドメイン層の隔離について
[DDD]ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か - Qiita
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっ
![[DDD]ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/695d93e74e7988d9edd27070ab82988908d811ef/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCREREJTVEJUUzJTgzJTg5JUUzJTgzJUExJUUzJTgyJUE0JUUzJTgzJUIzJUU5JUE3JTg2JUU1JThCJTk1JUU4JUE4JUFEJUU4JUE4JTg4JUUzJTgxJUE3JUU1JUFFJTlGJUU4JUEzJTg1JUUzJTgyJTkyJUU1JUE3JThCJUUzJTgyJTgxJUUzJTgyJThCJUUzJTgxJUFFJUUzJTgxJUFCJUU0JUI4JTgwJUU3JTk1JUFBJUUzJTgxJUE4JUUzJTgxJUEzJUUzJTgxJUE0JUUzJTgxJThEJUUzJTgyJTg0JUUzJTgxJTk5JUUzJTgxJTg0JUUzJTgyJUEyJUUzJTgzJUJDJUUzJTgyJUFEJUUzJTgzJTg2JUUzJTgyJUFGJUUzJTgzJTgxJUUzJTgzJUEzJUUzJTgxJUFGJUU0JUJEJTk1JUUzJTgxJThCJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz05OGYwZGRhOTVkYzJhZDMwNTVlYzE4NTQ4ZGQ5NTE5MQ%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbGl0dGxlX2hhbmRfcyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9M2M3NjhmN2VjOTAyM2RiNTMyMGEzMjE4ZDU3NGE0NjY%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D9b89acc5c201613d02a94a12f5733bfa)
UCDとDDD - ユースケースからユーザー中心について考える
ユーザ中心に考えるためにヒト・コト・モノの概念を抽出し、ユビキタス言語を定義することでの齟齬をなくしたり、概念を浮き彫らせたりのメリットやその抽出フローなどをまとめました。 ＊これはDesign For User 勉強会#1 http://design-for-user.connpass.com/event/26425/ でお話したスライドです。
UseCaseの再利用性 - yoskhdia’s diary
Clean ArchitectureにはUseCase層が定義されていますが、このUseCaseが一体どういうものなのか度々わからなくなるので、自分の考えをまとめてみるエントリです。 Clean Architectureについてはこちら 8thlight.com 日本語訳：クリーンアーキテクチャ(The Clean Architecture翻訳) 以降、概念を”ユースケース”、実装されるモノを”UseCase”と表記することにします。 （同じっちゃ同じなんですが、指してるものがところどころ変わるので表記分けをしています。） また、Webアプリケーションを想定しています。 ユースケースとは何なのか Clean Architectureから抜粋します。 Use Cases The software in this layer contains application specific busi
DDDの仕様パターン - pospomeのプログラミング日記
-----------追記------------- 仕様パターンについては以下の書籍で可能な限り詳しく解説しています。 興味あれば読んでみてください。 pospome.booth.pm -----------追記おわり------------- エリック・エヴァンスのDDD本では「仕様パターン」という実装パターンが説明されている。 仕様上のバリデーションはエンティティや値オブジェクトに実装してはいけない。 複雑な仕様による複雑なバリデーションロジックは クラスの肥大化を招いてしまう。 class User { //こういったバリデーションは肥大化を招く public boolean isXXX(){ //複雑なロジック } } また、こういったバリデーションは複数のエンティティを必要とする場合があるので、 どのクラスの責務とするのかを明確に判断できないこともある。 class User
なぜDDD初心者はググり出してすぐに心がくじけてしまうのか - little hands' lab
背景 直近のプロジェクトでDDDの思想に則ったアーキテクチャで一つリリースまで漕ぎ付けまして、そこに至るまで色々と調べたり試行錯誤をしながら学んだことを書いていこうと思います。 一番にですね、大体のDDDに興味を持った人がいうのが 「単語が難しいばかりで結局イメージが湧かない」 「ドメイン駆動の本を読もうとして速攻で心が折れた」 ということなんですよね。 DDDは思想としてすごく面白く、とても実用性なものなのに、なんでこんなにわかりづらいのか、ハードルが高いのか！！ という点について、私なりの解釈を述べたいと思います。 心をくじく要因 Eric Evans本は説明が圧倒的に下手。笑 ドメイン駆動設計といえば原著がこの本(以下、原典)なのですが、 エリック・エヴァンスのドメイン駆動設計 この本は本当〜〜〜にわかりづらいです。重要なことは確かに書いてあるんですが、構成がかなりしんどくてまとまり
サーバレス、これからどうなる？ DDD＆サーバレスの第一人者が語る、技術の未来
注目しているサーバレスサービス 佃松三郎氏（以下、佃）：次ですね。「今注目しているサーバレスのサービスがあれば教えてください」。 丹羽一智氏（以下、丹羽）：サーバレスのサービスというと定義が難しいですけど。「サーバレスで開発されたサービス」なのか「サーバレス開発で使えるサービス」なのかというところで定義が難しいですが、そもそも世の中にフルサーバレスで動いているアプリケーションはほとんどないのが現状なので、「開発で便利なもの」という意味だと、何回か推しているんですが、Datadogがすごくおすすめです。 普通のアプリケーション開発をしていてもそうだと思いますが、「ログの扱いをどうしよう？」ということがずっと課題になっていて、Fluentdで集めてS3に置くということを、みんながんばってやっています。 DatadogにはLogsというサービスがあって、特定のポートにあるサービス、IP・ポートに
ドメイン駆動設計、どこまでやるべき？ 開発現場の“問題”を乗り越えるためにできること
ゲーム開発におけるドメイン駆動設計とサーバレスアーキテクチャ 佃松三郎氏（以下、佃）：みなさん、こんにちは。最初に「TECH × GAME COLLEGE」についてお話しさせてもらいたいと思います。 私はテクロスCTOの佃と申します。 ゲーム会社が主催する勉強会というのは数多くありますが、ゲームに特化した、もしくは「ゲームっていろんな技術を使ってるよね」という話があるなかで、「本当にゲームにフォーカスするオープンなコミュニティがないな」というところで、去年の8月からこの勉強会がスタートしました。 そこで「DDD」と呼ばれる開発手法について増田さんに登壇いただいたところからスタートしました。今回、ちょうど半年ということで、1つ区切りのイベントとして今回は開かせていただきました。 それでは、今日パネラーとして参加していただく増田さん、まずは簡単に自己紹介と最近取り組まれていることなどをお
Laravelで実践クリーンアーキテクチャ - Qiita
この記事を書くにあたって Laravel について色々サポートしてくれた皆さまに向けてお礼申し上げます。ありがとうございました。 本記事はクリーンアーキテクチャに対する理解を深めていただくために、「実践クリーンアーキテクチャ」の内容を Laravel で実装して解説するという内容になっています。 記事のゴールは「クリーンアーキテクチャに対する理解を深めてもらう」というものです。つまり、この実装の形は一例に過ぎません。 はじめに 皆さんクリーンアーキテクチャはご存知でしょうか。 そう、こんな図のアレです。 The Clean Architecture: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html クリーンアーキテクチャといえばこちらの象徴的な図をまずは思い浮かべるでしょう。 この図を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
形から入ったドメイン駆動設計によるゲーム開発の光と闇