s_ryuukiのブックマーク - はてなブックマーク

アジャイル迷子のための「アジャイルの本質」。あとDDDとのつながり - little hands' lab

記事の構成アジャイルソフトウェア開発とはアジャイルマニフェストとはアジャイルマニフェストの問題そこで、アジャイルの本質 by マーティンファウラーアジャイルソフトウェア開発とは？アジャイルソフトウェア開発とはなんでしょうか？「アジャイルマニフェスト(後述)の4つの価値観、12の原則に従う開発方法の総称」これが最もオリジナルな定義です。なぜこんなややこしい言い回しをするのは後から説明します。重要なことは、「アジャイル」という具体的な手法があるわけではないということです。アジャイルはマインドセット(思想、考え方)です。そのため、 ✖️ do agile 「アジャイルをやる」はありません。 ⭕️ be agile 「アジャイルになる、アジャイルの思想に則る」はあります。アジャイルの思想に則った開発手法として・スクラム・エクストリームプログラミング(XP) ・リーンスタ

s_ryuuki 2022/06/28

Agile

リンク

簡単にできるDDDのモデリング - ドメイン駆動設計 - little hands' lab

DDDではよく「モデリングが重要だ！」と言われますが、どのようにモデリングすればいいのかがわからず、一歩を踏み出せないことは多いのではないでしょうか。そんな方のために、本記事ではDDDにおいてシンプルで成果が出しやすいモデリング手法について紹介します。 (本記事は、YouTube動画「10分でわかるドメインモデリング」の内容をもとにした解説記事です。) DDDの目的 DDDの目的から確認しましょう。 DDDの目的は2つ。 ①機能性を高めることこれは、役に立つものを作ること、言い換えると「作ったけど使えない」を避けることです。そのために、ドメインモデリングを行い、ソフトウェアを適用して役立てようとしている現実世界の領域(これの領域をDDDでは「ドメイン」と呼びます)について理解を深め、解決策を検討することを目指します。 ②保守性を高めることこれは、長期間開発しても機能拡張が容易であり

s_ryuuki 2022/06/06

DDD

リンク

DDD基礎解説：エンティティ、値オブジェクトってなんなんだ - little hands' lab

はじめに DDDの実装パターンとして、エンティティと値オブジェクトというものがあります。ドメイン駆動一般に複雑な抽象論が多い中で、コードに近く一番イメージがつきやすいコード事例として出てくるため、ここだけは何となくわかるぞ！という方もいらっしゃるのではないでしょうか。今日はこちらの概要とそれぞれの使い道について書きたいと思います。先にざっくりイメージ図をお伝えすると、こういう図を使って解説します。何の目的で作るのか？ドメイン駆動設計は何を解決しようとしているのかこちらの記事で、ドメイン駆動設計のアプローチは以下の2ステップがあるということを書きました。ドメインの問題を解決するための抽象的なモデルを作る. モデルをソフトウェア(コード)に落とし込む ※ ドメイン＝ソフトウェアを適用して問題解決しようとする領域 DDDでは、このStep2のモデルをコードで表現するためのパターン

s_ryuuki 2022/04/05

DDD

リンク

設計/コードレビューで"常に"心がけるポイント - little hands' lab

株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatena blog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか高凝集クラスに関してメソッドに関して低結合 ③ユニットテストを書きやすいか合言葉筆者執筆書籍現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。

s_ryuuki 2022/01/28

リンク

ドメイン知識とユースケースの違いは何か？[ドメイン駆動設計][DDD] - little hands' lab

DDDの文脈の中で、「ドメイン知識とユースケース(≒アプリケーションの知識)は何が違うのか？」という疑問がよく持たれます。この記事ではその違いを説明し、DDDのコードにどう反映するかを書きます。あるToDoアプリの仕様事例として、ToDoアプリの話をします。「仕様を決める」と言ったとき、以下のように箇条書きで決めることがあると思います。(Jiraのようなチケット管理システムのチケット詳細として書いたりしますよね) ユーザー登録、非活性化ができるメールアドレスは重複登録できないタスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができるタスクは3回までしか延期ができない非活性化されていないユーザーにアサインができるタスクを完了、アサインするとタスクレポートが作成されるこれはいわゆる「ビジネスロジック」と呼ばれて、3層レイヤーのアーキテクチャではBusine

s_ryuuki 2021/02/17

DDD

リンク

ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab

この記事はドメイン駆動設計 Advent Calendarの記事です。今年の9月にログラスというスタートアップに転職しました。ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。入社時の状況なにをしたかテストの話が多い理由実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにしたレイヤーごとのオブジェクトの依存関係を整理レイヤーごとのテスト方針クラス名の重要性参照実装を作成した「責務」と「テスト」の重要性

s_ryuuki 2021/02/01

DDD

リンク

議論が噛み合わないと思ったら、「問題解決の5階層」でどこがずれているのか確認する - little hands' lab

チームで議論するときに常に心がけているのが、「問題解決の5階層」です。この図で重要なことは、下の階層で認識が一致していないと、上の階層では絶対認識があわないということです。「あれ、議論が噛み合っていないな？」と思ったら、この階層に照らし合わせて認識があっていないことがないか確認しましょう。問題認識のすれ違い例えばこのように問題の認識の違いがあったとします。なぜ違いが生まれたのでしょうか？コードの保守性に関する経験や、スキルの違い？と考えてしまうかもしれません。でも実際は、こうでしたこの話題に出てきたときの、認識していたコードが違うものだったのです。このような場合、事象の認識を合わせて初めて、問題の認識を合わせることができます。このようなケースは非常に多いです。普段一緒の空間で仕事をしていても、個人作業をしている時間は多いほど、人によって見えているもの、体験したこと

s_ryuuki 2020/07/18

マネジメント

リンク

新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab

ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かドメイン駆動 + オニオンアーキテクチャ概略以前こちらの記事でアプリケーションアーキテクチャについて書きました。こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。アプリケーションアーキテクチャ全体図とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。何かについて議論をする際は、「それはどの層の責務なの？」という