はてなブックマーク

ドメイン駆動設計の定義についてEric Evansはなんと言っているのか の記事の中で、EricEvansのドメイン駆動の定義を引用して以下のように和訳しました。 ドメインの中核となる複雑さと機会に焦点を当てる ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する 明示的にそれらのモデルを表現するソフトウェアを書く 境界付けられたコンテキストの中のユビキタス言語で話す この中で、重要なポイントが明示されていませんでした。 定義にある4点のようなことを、なぜやる必要があるのか？ ということです。 つまり、ドメイン駆動設計は、一体何を解決しようとしているのでしょうか？ ドメイン駆動設計は何を解決しようとしているのか DDDはソフトウェア開発手法の一つです。 なのでまず、ソフトウェア開発の目的について考えてみましょう。 人々はなぜ、ソフトウェアを開発するのでしょうか？ それは、

シリーズ記事：ドメイン駆動設計解説シリーズ ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か - little hands' lab ドメイン駆動 + オニオンアーキテクチャ概略 - little hands' lab これらの記事で書いた通り、私はDDDのレイヤードアーキテクチャを決める際にオニオンアーキテクチャの用語を使っています。これまで色々な人に説明してきて、理解につまづきやすいポイントとしてレイヤの責務の話があったので、そこについて解説します。 一発で伝わりにくい(と思っている)定義 Onion Architecture Is Interesting - DZone Java こちらの記事で書かれている各レイヤの説明 Domain Layer Domain Model layer, where our entities and classes closel

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか？という話を書きます。 境界づけられたコンテキスト実装の基本イメージ 結論からいくと、基本的には、 1コンテキスト = 1アプリケーション と思ってもらってOKです。 これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。 つまり、

googleスプレッドシートの複数人でファイルを同時に編集する機能、とても便利ですよね。 ただ、フィルターをかけようとしたら他の人の表示もフィルターされてしまい、困ったことはありませんか？ 「フィルター禁止！」なんて運用ルールになり、非常に不便な思いをしているケースを見たことがあります。 実は、わかりづらいですが解決策があるので、それをご紹介します。 「フィルタ表示」機能を使う 絞り込み対象の 「データ > フィルタ表示 > 新しいフィルタ表示を作成」 とクリックしていきましょう。 画面の表示が変わり、データの周りの領域がグレーの表示になりました。 これが「フィルタ表示」機能が有効になっている状態です。 このフィルタ表示状態にしてから絞り込みを行うと、他の人には影響を与えずに、自分だけ絞り込み表示をすることができます。 ↑他の人から見ると絞り込なれていない状態で表示されている 仕組み 実は

Pythonの__init__これなんて読むのかと思ってたら、"dunder init"と読むらしいです。 python wikiに書いてあることを抜粋すると、 とあるインターネット上のフォーラムにてMark Jacksonと言う人が以下のように提案したのが発端らしいです。 An awkward thing about programming in Python: there are lots of double underscores. My problem with the double underscore is that it's hard to say. How do you pronounce __init__? "underscore underscore init underscore underscore"? "under under init under under"?

#aliasの設定方法 Windowsではコマンドマクロという機能を使用して、aliasと同じ設定が可能。 Windowsのコマンドプロンプトにて、 doskey ｛マクロ名｝=｛実行コマンド名｝ とすればよい。 ただし、一度ウインドウを閉じると設定が消えてしまうので起動時に自動読み込みさせる必要がある。 #設定のテキストファイル化 設定されているdoskeyは doskey /macros で表示できる。 これを利用してテキストファイルとして出力する。 doskey /macros > %USERPROFILE%\macros.txt このファイルを読み込むときは doskey /macrofie=%USERPROFILE%\macros.txt とする。 #コマンドプロンプト起動時の読み込み コマンドプロンプト起動時の/kオプションで、上記コマンドを実行するように設定する なお、kオプ

ということなんですよね。 DDDは思想としてすごく面白く、とても実用性なものなのに、なんでこんなにわかりづらいのか、ハードルが高いのか！！ という点について、私なりの解釈を述べたいと思います。 心をくじく要因 Eric Evans本は説明が圧倒的に下手。笑 ドメイン駆動設計といえば原著がこの本(以下、原典)なのですが、 エリック・エヴァンスのドメイン駆動設計 この本は本当〜〜〜にわかりづらいです。重要なことは確かに書いてあるんですが、構成がかなりしんどくてまとまりがないのです。一通り実装してからも結局この結論になるので、あの本でわからないのは仕方ないです。笑 まず書籍は実践DDD(以下、IDDD)から入るのが良いと思います。 実践ドメイン駆動設計 ここである程度イメージをもたせてから、興味があったら原点に当たるというのが良いでしょう。 DDDは対象領域が広いが、それが理解されずそれぞれ局所

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 先日、メディアマックスジャパン様(以下、MMJ様)にお邪魔してドメイン駆動設計勉強会を開催してきました。そちらで質疑応答セッションがあり、実際にドメイン駆動設計で開発をしだしたタイミングで出てきた具体的な疑問について色々お答えしました。 おそらく多くの人が同じような疑問を持たれそうな内容だったので、MMJ様の許可を得てこちらでも紹介したいと思います。 コンテキストの分け方について DBを複数コンテキスト共通でつかっていいのか？ スキーマわけなくていいのか？ コンテキストごとにスキーマは最低限分けることをオススメしています。詳細は以下の記

DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 ドメイン駆動設計について、「どうやって実装するのさ？」の前に、まずは定義について認識合わせをしたいと思います。 背景 「ドメイン駆動設計とは何か？」 ドメイン駆動設計について興味を持った時に、一番最初に疑問に思うのがこれですね。 ところが、ググって見ると結構いろんなサイトでいろいろな書きぶりをしているんですよね・・・。 「顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法」 ドメイン駆動設計のメリットと始め方(Codezine記事) 「厳しい現実の中で、

境界付けられたコンテキストとは 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界付けられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界付けられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界付けられたコンテキスト ・境界付けられたコンテキストをどう実装に

DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 はじめに 設計の善し悪しについて日々色々と議論することはあると思いますが、「良い設計」「悪い設計」について明文化した定義はあるでしょうか。各々の頭の中にぼんやりと、もしくは断片的にはあるものの、チームで良し悪しについて定義まですることはあまり多くないのではないでしょうか。 各プロジェクトで議論することには価値があると思いますが、一つ基準になるものがあると議論しやすいと思います。そこで一つ、オブジェクト指向の原則を提唱したUncle BobことRobert Cecil Martinが提唱

DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを

仕様、制約条件といった様々な呼び方がありますが、DDDの用語としては不変条件、という言葉を使うのでそれで統一します。 ドメインの知識を表現していないモデル 例えば、とある業務アプリケーションでタスクというものをモデリングするとします。要件定義したところ、以下の不変条件を満たす必要があるということがわかりました。 タスクは必ずタスク名、期日を持つ タスクは未完了状態で作成し、完了したら戻すことはできない タスクは3回だけ、1日ずつ延期することができる。 タスク名は変更することができない これを実装してみます。 ※ Spring Data JPA(Hibernate)を使用した実装イメージです。Spring Data JPAについてあまり詳しくなくてもイメージはわくと思いますが、不明な点は別途調べてみてください。 @Entity public class Task { @Id @Generat