『ドメイン駆動設計』の解説記事を書きました - ソフトウェア設計を考える
本日(1月18日)発売された、Software Design誌 2023年2月号の第一特集で「ドメイン駆動設計入門」を書きました。 執筆の意図と記事の概要を簡単にまとめておきます。 Software Design 2023年2月号｜技術評論社 執筆の意図 特集のサブタイトルにある通り「設計力を磨きたい」読者が、ドメイン駆動設計の基礎を知ることで「設計の手法とアイデアの引き出し」を増やすことの役に立てればと思い執筆を引き受けました。 重視したこと 断片的な用語やパターンの解説でなく、ドメイン駆動設計の全体像と要点を伝える 全体像を伝えるための図や表を多めにした（ソースコードの例は少ない） 全体像と要点は、原典である『エリック・エヴァンスのドメイン駆動設計』（以下『ドメイン駆動設計』）の説明を中心にした ドメイン駆動設計の具体例として『ドメイン駆動設計』に出てくる国際海上貨物輸送の具体的な業務
素のRailsは十分に豊かである（翻訳）｜TechRacho by BPS株式会社
はじめに 「Railsは関心の分離が不十分である」という批判をよく目にします。状況が深刻になったら、Railsに足りない別のピースを導入しなければならないというのです。しかし私たちはそうは思いません。 「素のRails（vanilla Rails1）ではここまでしかできない」みたいな批判を耳にすることがよくあります。Railsはアーキテクチャレベルで関心の分離が不十分なのだから、アプリはいずれメンテナンス不能になり、足りないピースを導入するという別のアプローチが必要になるというのです。 代表的なDDD（ドメイン駆動開発）書籍では、概念上の4つの層である「プレゼンテーション層」「アプリケーション層」「ドメイン層」「インフラストラクチャ層」について議論しています。 アプリケーション層は、ドメイン層と協調動作してビジネスタスクを実装します。しかし、Railsが提供しているのは「コントローラ」と「
設計/コードレビューで"常に"心がけるポイント - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 ドメイン層のオブジェクトを設計する際に、重要な基本方針があります。 ドメインモデルの知識を対応するオブジェクトに書く 常に正しいインスタンスしか存在させない この2つを守ると、非常に保守性の高いコードにすることができます。 以下、詳細に解説します。 ドメインモデルの知識を対応するオブジェクトに書く ドメイン知識(ルール/制約)を表現する実装を、ドメイン層のオブジェクトに寄せていきます。 この判断は、「ドメインモデル図に書かれた吹き出しの内容が、どの層で実装されているか」という基準に基づき行います。 この基準はコード設計の指針として非常に役立ちます。 設計の良し悪しというのはさまざまな基準があるため、レビューをしていてもいわゆる「俺の考えた最強の設計」同士が戦ってしまうことがあります。 しかし、「ドメイン知識はドメイン層に書く」と
![DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/cf7c2977c5538fe370d1ff60a78958464a9e1f3f/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20220125%2F20220125074432.png)
松岡@ログラス/DDD,アジャイル on Twitter: "DDDで設計する際に常に気を付けるべき、基本的な設計方針について解説しました。まずはこれを押さえるだけでかなり実装方針を整えることができます。#ドメイン駆動設計 https://t.co/ScEAz0yXiv"
DDDで設計する際に常に気を付けるべき、基本的な設計方針について解説しました。まずはこれを押さえるだけでかなり実装方針を整えることができます。#ドメイン駆動設計 https://t.co/ScEAz0yXiv
Webフロントエンドの開発効率を高く保つための考え方
これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://x.com/shibu_jp/status/1750290378539073688?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://twitter.com/sonatard/status/1659546083406774272?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://twitter.com/sonatard/status/1629395764752572419
https://twitter.com/minodriven/status/1621448957682663424?s=12&t=89UN6VxGo4meCGfwBGB4HQ
Shunsuke on Twitter: "@yum3_tech この本ですか？ https://t.co/sT7rFJX9Vv"
https://twitter.com/fetarodc/status/1523427809800372224?s=12&t=j6_2YABiMF78WrVOFzibTA
かとじゅん on Twitter: "頭がよい人が雑に書いたテストコードはだいたいアサーションルーレットになってて、テスト対象のメソッドも複数の責務を持ってる。だからリファクタリングも難しい。こういうのを防ぐためにTDDはやはり必要なガイドだと思える"
増田 亨． on Twitter: "４つの設計スタイル： ①トランザクションスクリプト Sting/intがフラットに並ぶデータ構造と処理手続き ②アクティブレコード より複雑なデータ構造と処理手続き ③ドメインモデル ビジネスロジックとビジネスデータのカプセル化… https://t.co/KgUXAbkTEB"
増田 亨． on Twitter: "この本は、ドメイン駆動設計をアプリケーション開発にどう生かしていくかの実践的な手引きとしても、とてもよい内容が詰まっている。 特に後半は、規模が大きめの業務アプリケーション開発で参考になる点が多い。 オンラインイベントで紹介してみ… https://t.co/nc3ZLITgc4"
モンゴル on Twitter: "友人に誘われ「現場で役立つシステム設計の原則」のサンプルコードをtypescriptで実装中 https://t.co/mj08GbZKVy やっぱり、実装してみると、色々気づくことがある"
kawasima on Twitter: "ドメインモデル貧血症対策は、setterをなくすこと(だけ)じゃないよ、というのを書きました。 https://t.co/Pus3CoIV7z"
松岡@ログラス/DDD,アジャイル on Twitter: "https://t.co/dXrJ8jOfjD #ドメイン駆動設計の導入"
奥野 賢太郎 | Motifaryの中の人 on Twitter: "Reactのクリーンアーキテクチャは、もうなんか細かいことを考えずにSOLID原則…というかもうS（単一責任原則）だけ気にしておけば十分で、だらだら書くな、むやみな依存ツリーを組むなの二点です。あとは、多少優劣あっても、なんとでもなります。"
あきの/D-En on Twitter: "ちなみにIPA系試験の過去問と解答（完成系のER図）は両方とも無料で配布されているので、教材としてお手軽に手に入るのでおすすめです！ （解説はないので知りたい場合は自分で調べるか参考書が必要） https://t.co/8Lh0oRUHtF"