ドメイン知識を隠すコード、隠さないコード - Magnolia Tech
2021/12/20追記 指摘されて気づいてしまいましたが、間違ってますね... 以前スライドを書いた時に全然気づいていませんでした 反省のために消さずに、取り消して残しておきます 「年齢計算ニ関スル法律」という法律がある。 明治三十五年法律第五十号（年齢計算ニ関スル法律） | e-Gov法令検索 とても短い法律で条文は3つしかない。 ① 年齢ハ出生ノ日ヨリ之ヲ起算ス ② 民法第百四十三条ノ規定ハ年齢ノ計算ニ之ヲ準用ス ③ 明治六年第三十六号布告ハ之ヲ廃止ス ポイントは①で、生まれた日から起算するので法律上は1年が経過した時に1つ歳を取ることになる。つまり、誕生日の前の日の24時に年齢が加算されるので、日単位でみると誕生日の前の日にもう年齢は進んでいる、ということになる。 同じ年の4月2日生まれの人と、4月1日生まれの人とでは小学校に入学する年度が違う、というのはよく聞く話だと思う。 この
リファクタリング自爆奥義集 - Qiita
【対策】必ず課題と効果を確認すること リファクタリング対象のコードに、どんな課題があるか確認しましょう。 課題に相応しいデザインパターンがあるならば、適用して良いでしょう。 デザインパターンを適用した場合、期待通りの効果が発揮されたかどうかを確認してください。 たとえばStrategyパターンは、条件分岐のコピペコードを削減する効果があります。 Strategyパターン適用後、分岐コピペがあまり減らなかったのであれば、設計を見直しましょう。 ◆奥義３ : 共通化しちゃいけない箇所を共通化 重複コードがあると、仕様変更時に重複箇所を全て修正しなければならなくなります。修正漏れがあるとバグ化します。 重複解消のため、処理を共通化することがよくあります。 しかし共通化してはいけないものがあります。 そうしたコードを無理に共通化すると密結合に陥り、逆に変更容易性が低下します。 私が制作した動画「共
クリーンアーキわからんかった人のためのクリーンじゃないけどクリーンみたいなオニオンに見せかけたSOLIDの話
依存関係逆転則含む諸原則に苦しめられた方々，いかがお過ごしでしょうか． 今回はアプリ設計の話です．と言っても，前回「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」というZenn記事を書いて，反響が大きかったのでリメイクしたいなという気持ちになり執筆することにしました． 前回同様，調べていく上で誤解していた部分や理解しにくかった部分を語った上で，オニオンアーキテクチャという，クリーンじゃないけどクリーンみたいな玉ねぎについて紹介するのですが，今回はわかりやすい図解であったり，実際にどのような実装をしていくべきなのかを話の話題として加えていければ良いかな？って思っています． これは前回の記事である「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」の記事の裏話的な話を一つさせてください． 今年の11月初め頃に，サポーターズという企業の学生が登壇できるLT会があり，私
設計を歪める認知バイアス - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに？ ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 本記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的と
ドメイン駆動設計とイミュータブルなクラス設計
クラスをイミュータブルに設計するパターンの紹介 ・閉じた操作 ・withメソッド ・イベントリポジトリ＆集約ファクトリ
アプリケーションをドメインモデルで設計する - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 親記事 : https://qiita.com/Regpon/items/1116679adadd8fb76f3f ドメインモデルで設計する狙い オブジェクト指向プログラミングにおいてかなり重要な内容となっているが如何せん概念的な内容となっている。ドメインモデルを設計するには幾度とない失敗の経験を重ねていき、常に改良していく精神が重要。そのための指針となる内容なので是非とも押さえておきたい。 それを踏まえてドメインモデルで設計する狙いは以下の通り。 業務的な判断・加工・計算のロジックを重複なく一元的に記述できる 業務の関心事(データ)と
クラス設計本格入門 JJUGナイトセミナー 2021-6-16
イベントの動画 : https://www.youtube.com/watch?v=2Z1CJhPk-f8 オブジェクト指向プログラミングはクラス設計。 クラス設計はプログラムの分割。 クラス設計の焦点は、ビジネスルールを表現するクラスと、ビジネスアクションを表現するクラス。 クラス設計やパ…
運用に耐えられるコードを書くために - Magnolia Tech
オブジェクト指向とか、DDDとか言う前に、「落ちる時は速やかに落ちる」「原因がきちんと解析できる情報を出す」「リトライポイントが用意されている」「最終的な結果の正当性、整合性を確認する方法が用意されている」っていうコードをですね.... https://t.co/I5bIfhZYN8— magnoliak🍧 (@magnolia_k_) 2021年5月3日 異常系への対処がちゃんとできているコードが書けるようになってこそ一人前、みたいな、そんな価値観— magnoliak🍧 (@magnolia_k_) 2021年5月3日 いや、その手前の「つべこべ言わず、エラーが起きる可能性があるところは全てエラーコードをチェックする」なんだよ https://t.co/zmJBWR0ybX— magnoliak🍧 (@magnolia_k_) 2021年5月3日
「DDDで複数集約間の整合性を確保する方法」に対する考察 - かとじゅんの技術日誌
久しぶりにブログ記事を書きますか。 ということで、松岡さん(id:little_hands)のブログ記事に対する考察記事です。 この記事は古くなったので、ぜひ以下も参照してください。 blog.j5ik2o.me little-hands.hatenablog.com 題材も松岡さんのブログ記事と同じもので考えます。 「実装方法1. ユースケースで複数集約を更新する」について考察したいと思います。 注意事項）この記事で使うトランザクションという用語は単なる一連の手続きという意味ではなく、ACID特性を持つRDBのトランザクションという意味です。 class CreateTaskUseCase1( private val taskRepository: TaskRepository, private val taskReportRepository: TaskReportRepository
単一責任原則で無責任な多目的クラスを爆殺する - Qiita
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
再考 - ドメインサービス - まっちゅーのチラ裏
自分が大規模システムで組むアーキテクチャは基本的にはCleanArchitectureを踏襲しているが、その中の構成要素であるドメインサービスだけは少し独自(?)の解釈をしていて、書籍などでよく見る ビジネスロジックを持つが、状態をもたない 複数の集約にまたがる処理を書く場所 という責務の他に、外部システムへの委譲処理だったり、共通UseCaseのような責務も持たせている。 これは、自分が「xxService」という命名にトラウマがあり(何でも置き場になりがち)、単なるServiceだとコントローラやらプレゼンターやら、どこから呼ばれても違和感がない様に見えてしまうから、とりあえずDomeinServiceへ寄せている経緯がある。 ※ここで語るのは、あくまで大規模想定で、小さいシステムならこんな事を意識する必要はないはず。 ※あくまで自分の考えで、一般的ではない可能性があることをご了承くだ
設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita
/// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary> /// <param name="amountExcludingTax">税別金額。</param> /// <param name="salesTaxRate">消費税率。</param> /// <returns>税込金額。</returns> public int CalculateAmountIncludingTax(int amountExcludingTax, decimal salesTaxRate) { return (int)(amountExcludingTax * (1.0m + sales
実践DDDのサンプルプロジェクトが学びしかない - Mitsuyuki.Shiiba
IDDDを読んで、それなりに書いてあることは分かり始めたかな。と思ってたけど。 いざサンプルプロジェクトを読んでみたら、全然そんなことなかった。(ﾉД`)ｼｸｼｸ github.com いつものように、自分メモ。 プロジェクトの構成 全部で3プロジェクトと1ライブラリがある。 iddd_agilepm データストアとしてKVS(LevelDB)を使用。 DIコンテナは使ってない。 iddd_collaboration Event Sourcing と CQRS。ORM使わずにやってみた。 例をシンプルにするために、Event Sourcedな書き込みモデルと、CQRSの読み込みモデルを1スレッドで実行してる。イベントジャーナルとしてLevelDBを、リードモデル用にMySQLを使ってるのでほんのちょっとだけ一貫性がない状態が発生する可能性がある。別々のデータストアを使って、でも、できるだけ
境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
境界づけられたコンテキストとは 公式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] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/9937daa254a41c5056666b79af8b3df3f2fd5d30/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F32039c959bfcd9d3964a49b1cde6b8c986b5d171%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20171128%252F20171128072027.png)
JSUG勉強会 2017 - 3 〜ドメイン駆動設計 powered by Spring のメモ - mike-neckのブログ
JSUGの勉強会に参加したので、そのメモ。 jsug.doorkeeper.jp 資料は公開されるだろうから、ここでしか聞けないことを中心にメモ(ツイート)したつもりだが、資料に盛り込まれている可能性は十分にある。なお、資料は以下の通り。 ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring from 亨 増田 www.slideshare.net 個人的な感想 ドメイン駆動のセッションや話は「ドメイン駆動はいいぞ」という感じで抽象的な話になりがちなことが多いのだが、今回はフレームワークが限定されたこともあってどのようなオブジェクトをどのように作っていくという具体的な話が聞けて満足だった ビジネスルールとドメインロジック ビジネスルール(契約・法令・明文化されていない商習慣)などがソフトウェア開発の分析対象(もちろん、ビジネスルールがゲームのルールだったりサー
DDD の Java EE 実装サンプル - Cargo Tracker を読み解く - Qiita
レイヤ化アーキテクチャ（LAYERED ARCHITECTURE） DDD でのレイヤ化アーキテクチャ アプリケーションの中では、ドメインのロジック以外にも様々な処理が行われる。 例えば、画面表示に関する処理・トランザクション制御・データベースアクセス・メール送信などがある。 もし、これら他の関心事の中にドメインロジックが紛れ込んでいると、コードは非常に読みづらくなり保守もしづらくなる。 この問題を回避するため、ドメインは他の感心事から分離しなければならない。 分離の手法は多々あるが、一般的に広く受け入れられている手法として、レイヤ化アーキテクチャがある。 レイヤ化アーキテクチャでは、アプリケーションが持つ関心事をいくつかの層に分離する。 各層に含まれる要素は、同じ層内の要素かもしくは下位の層にのみ依存し、上位の層には依存しないようにする。 上位の層と連携する場合は、コールバックやオブザー
今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
リーダブルコード、あるいはコードコンプリートについて - mizchi's blog
リーダブルコードから学べるのは嘘メソッド名と嘘コメントが最大の罪ってことだよ— 片手間以上 (@mizchi) 2014, 7月 5 コードコンプリート、個人的にそんな有益な話はなかったという記憶なんだけど単に趣味のドメインが違うだけかもしれない可能性はある— 片手間以上 (@mizchi) 2014, 7月 5 コードコンプリート、作者が一生懸命になってる主張の部分が全然共感できないのがあった— 片手間以上 (@mizchi) 2014, 7月 5 僕はGoFはむしろ初心者に絶対に読ませてはいけない本だと認識していて、グローバル変数をファサードとか言い出したり、これはシングルトンなんです！と言い出す— 片手間以上 (@mizchi) 2014, 7月 5 本読んでコード書けるようになるとか幻想だと思ってるので、基礎文法覚えたあたりでコードコンプリート読んで、その後はいろんなパラダイムのフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン駆動設計基礎講座〜戦略編〜
