"Object-Oriented Conference 2024" の登壇資料です。 https://ooc.connpass.com/event/305241/
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
"Object-Oriented Conference 2024" の登壇資料です。 https://ooc.connpass.com/event/305241/
DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
【Go】DDD + レイヤードアーキテクチャでREST APIを実装する | みんたく
Go + DDD + レイヤードアーキテクチャを本やネットで調べ、実際に動かしながらREST APIを構築してみました。 ドメイン駆動設計の本や記事を読んでも実際に自分の手でやってみないと身につかないと思い、簡易的ですが使えるところまで実装してみました。 DDD（domain driven design）とはDDD(ドメイン駆動設計)とはソフトウェアの設計手法であり、ドメインモデリングに着目してソフトウェアの価値を高める手法です。 ソフトウェアの核心にある複雑さに立ち向かうため、チームの共通言語である「ユビキタス言語」を用いて「ドメインモデル」を構築し、それをコードとして実装します。 また、大規模で密結合なシステムにならないように「ドメイン」と「境界づけられたコンテキスト」にシステムを分割し、「コアドメイン」という最重要領域に集中して開発を行います。 DDDについてはまだ理解が浅いので、今
一迅プラスのインフラ構成について - BOOK☆WALKER inside
こんにちは。 メディアサービス開発部バックエンド開発グループのフサギコ(髙﨑)です。 Ruby on Railsによるバックエンドの実装運用と、AWSによるサービスインフラの設計構築を中心とした、いわゆるテックリードのような立ち位置で働いています。 本記事では株式会社一迅社さまの公式漫画連載サイトであり、ブックウォーカーが開発保守運用を担当している一迅プラスのサービスインフラの概要についてご紹介したいと思います。 もしよければ、前記事のニコニコ漫画のインフラ構成についてならびに読書メーターのインフラ構成についてもご覧ください。 一迅プラスについて 一迅プラスは株式会社一迅社さまが運営する公式漫画連載サービスです。 冒頭試し読みから連載まで、2022/06/10現在で150を超える作品が掲載されています。 一迅プラスのトップページ この一迅プラスにおいてブックウォーカーは開発保守運用を担当し
DDDを実践するための手引き（リポジトリパターン編）
以前DDDの入門記事を書いたのですが、ここではリポジトリパターンについて深掘って取り上げます。続編ぽいタイトルですが、そんなにつながりはないのでコレ単体で読めます。 はじめに リポジトリパターンは、DDDで有名になった、ドメインモデルの永続化のためのデザインパターンです。 今やいろいろなところで「Repository」という名前を冠するクラスを目にするようになりましたが、誤解されたり誤用されることも多くあります。 ここではリポジトリパターンの意図や本質を理解することを目指します。リポジトリパターンには役立つ考え方が詰まっているので、このパターンを採用しなくても知っておくときっと役に立つと思います。 なお実装例はKotlinで書きますが、オブジェクト指向の言語であればだいたい同じ感じです。 リポジトリ（Repository）とは？ 日本語訳は「保管庫」です。オブジェクトを保管しておき、必要な
メモ:値オブジェクトの定義と差異について - かとじゅんの技術日誌
「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。 すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。 もし読むなら興味がある人だけで。 自分向けのメモですが、一応 この記事の前提や意図を書いておきます。 「DDDの値オブジェクト」以外を否定する記事ではありません。 原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか 下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。 言い訳と
ユビキタス言語について - Qiita
こちら2つを読んで ユビキタス言語とは ソフトウェア開発チーム全体で作り上げる共有言語 ドメインのユーザーが使う用語とプログラムを構成する用語を一致させた言葉 プロダクトオーナー、開発者間のコミニュケーションを円滑にするためのようなもの ユビキタスとは 「満遍なく」とか「どこにでもある」という意味 ユビキタス言語の考え方 その業務自体が、どのような考えでどのように動くのか プロジェクトにとっての最善の用語か ユビキタス言語における変更は、モデルに対する変更である ドメインエキスパートは用語や理解を伝えるために適切かどうかに、開発者は設計を妨害する不整合さがないかどうかに着目すべき ユビキタス言語のスコープ チーム。チームによって話されて、チームが開発する単一のドメインモデルで表現される 「業界全体で」とか「全社的に」あるいは「世界中で」共通なドメイン言語を想定したものではない(ユニバーサル
ドメインモデル、ドメインロジックとは何かをコードを交えて考えてみる - Qiita
この記事について オブジェクト指向設計の文脈で度々目にする「ドメインモデル」や「ドメインロジック」というものが具体的に何を指しているのか、ドメイン以外のモデルってあるの？とか、じゃあアプリケーションロジックってなんだろう、というようなことをコードを交えて定義してみようという試みです。 はじめに コード例は、マルチパラダイムなプログラミング言語 PHP で書きます。 対象読者は「ドメインが何を指すのかよく分からない」と思っている方ですが、オブジェクト指向の猛者の方にも間違いがないか見てもらいたいので読んでほしいです。 そもそも「ドメイン」とは 語義 MACMILLAN DICTIONARY によると a particular area of activity or life domain (noun) American English definition and synonyms | Ma
Repositoryパターンのアンチパターン - Qiita
よく見かけるRepositoryパターンのアンチパターンの紹介と対策です。 Repositoryパターンとは Repositoryパターンとは永続化を隠蔽するためのデザインパターンで、DAO(DataAccessObject)パターンに似ていますが、より高い抽象度でエンティティの操作から永続化ストレージを完全に隠蔽します。 例えばDBコネクションやストレージのパス等はReposiotoryのインターフェースからは隠蔽され、Repositoryのユーザは永続化ストレージが何であるか(例えばMySQLやRedis等)を意識することなく保存や検索の操作を行うことができるようになります。 これによりRepositoryを利用するロジックは業務的な操作に集中できるようになる他、データベースの移行等の永続化層の変更が発生した際にロジックへの影響を切り離すことができるようになります。 // 例) ユーザ
Laravelで同じ実装をドメイン駆動設計(DDD)とMVCで比較してみた(フロントはReact) - Qiita
概要 Laravelで同じ実装をドメイン駆動設計(DDD)とMVCで比較してみました。フロントはReactで実装しています。設計思想はドメイン駆動設計(以下DDD)、アーキテクチャはクリーンアーキテクチャを採用しました。LaravelのWebアプリケーションをDDDやクリーンアーキテクチャで構築すると、MVCで構築するのと比べて実装量やファイル数が増えるのでは？また、処理速度も遅くなるのでは？という懸念を抱いておりました。ただ、それは実際に試してみないとわからないと思い、同じ機能をDDD、MVCで実装し、比較する事にしました。やるなら実践的なプロジェクトが望ましいし、イメージし易いと考えて、題材はECのデモサイトにしました。構築パターンは、DDD、軽量DDD、MVCの3パターンです。DDD、軽量DDDの違いは、DDDはクリーンアーキテクチャに忠実に実装したのに比べて、軽量DDDはPrese
DDD基礎解説：エンティティ、値オブジェクトってなんなんだ - little hands' lab
はじめに DDDの実装パターンとして、エンティティと値オブジェクトというものがあります。 ドメイン駆動一般に複雑な抽象論が多い中で、コードに近く一番イメージがつきやすいコード事例として出てくるため、ここだけは何となくわかるぞ！という方もいらっしゃるのではないでしょうか。 今日はこちらの概要とそれぞれの使い道について書きたいと思います。 先にざっくりイメージ図をお伝えすると、こういう図を使って解説します。 何の目的で作るのか？ ドメイン駆動設計は何を解決しようとしているのか こちらの記事で、ドメイン駆動設計のアプローチは以下の2ステップがあるということを書きました。 ドメインの問題を解決するための抽象的なモデルを作る. モデルをソフトウェア(コード)に落とし込む ※ ドメイン＝ソフトウェアを適用して問題解決しようとする領域 DDDでは、このStep2の モデルをコードで表現するためのパターン
【PHPでDDD】ドメイン駆動設計と上手く付き合う方法
私は小規模な会社の代表を務めながら現場でコードも書くフルスタックエンジニアです。 今回の記事では、会社経営や現場の両方から見たDDDと上手く付き合う方法の一つを紹介したいと思います。 あくまでも弊社で決定している開発方針になりますので、「推奨する」方法ではありません。この記事は一例に過ぎませんが、皆さんの参考になればと思います。 DDDの導入を拒む企業が多い理由 DDDの導入に否定的な企業が多いと感じます。その理由をざっくり上げてみます。 人材の教育が大変 開発のオーバーヘッドが大きい コストがかかる（インフラ、勉強、時間などのコスト） 導入のメリットがイマイチわからない ざっくりではございますが、こんな感じでしょうか。 DDDを商業プロジェクトに導入するまでの道のりは確かに長いです。また、データを軸に設計していた開発者に、ドメインを中心に設計する方法に慣れてもらう必要があり、手間がかかる
スタブとモックの違い - Qiita
オブジェクト指向設計実践入門を読んで学んだことのまとめです。 具体的にRspecでモックを書くときはこうしましょう、といった具体的な話ではなく言葉の意味の説明がメインです。 ソフトウェアテストの対象 スタブもモックもテストコード内で使うものです。違いを考える前に、テストについて振り返ってみます。 テストを行うべきなのは、次の2つについてです。 オブジェクトがほかのオブジェクトからメッセージを受け取ったとき、期待する答えを返すことができるか 要するにパブリックメソッドに対するユニットテスト 「オブジェクト指向設計実践ガイド」には、プライベートメソッドに対するテストは書くべきではない、さらにいうとプライベートメソッドを書くべきではない(プライベートメソッドを他のオブジェクトに切り出して注入せよ)とあります。 オブジェクトが副作用のあるメッセージ送信を行うとき、その回数や引数が適切か ログを書く
結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ？と思ったときの選択肢 - Qiita
自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf
バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング
こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する
Web2.0ナビ: SQL-DESIGNERがスゴイ
いいね！ 0 ツイート B! はてブ 447 Pocket 2 データベースの設計時にER図をかくことが多いと思いますが、SQL-designerというウェブベースのツールが非常に使いやすいく、デザイン的にも綺麗で便利。 MSproject等のデータベース設計を行う専用ソフトは非常に多くあるが、どれもインストールが必要だったり、設定ファイルが必要だったり、ソフトが重かったり、環境依存が激しかったりして、使いにくい。 使いかたは簡単で、 １．ウェブページにいって ２．テーブルやフィールドを追加する ３．プリントアウトorXMLエクスポート だけ。 データの型なども選択できて、設計が終わったら、SQL文をそのまま発行したり、作ったEQ図をXMLでエクスポートやインポートすることも可能。Javascriptベースなので、めんどくさいインストールや環境依存もなし。 ウェブ上でやるのは、セキュリティ
ITPro: 基本設計におけるレビューの勘どころ
どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「考慮していない外部システムとの連携が詳細設計で見つかった」，「仕様間の不整合が実装フェーズで発見された」――。どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「欠陥防止」を徹底する 改めて言うまでもないが，基本設計の成果物の品質を向上させるプロセスは，(1)設計作業を実施する，(2)成果物をレビューして欠陥を洗い出す，(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
バックエンドの設計で直したほうが良いコード9選
shiodaifuku.io
専門家は個人の責任で情報発信するな - void GraphicWizardsLair( void ); //