はじめに インターフェースとか抽象クラスとか、使い方をよく分かっていませんでした。 色々試行錯誤してみて、最近その恩恵というものが分かってきたので、自分なりの解釈を記そうと思います。 その考え方は正しい、間違っているとか是非コメントお待ちしております。 今回は言語はC#で書きます。 JavaやPHPといった他のオブジェクト指向言語でも基本は通じるのでパッと見わかるような内容になっていると思います。 最初にインターフェース、抽象メソッドについて概要。 その次に実際のコードとしてどう活用していくかを記していきます。 そもそもインターフェースとか抽象クラスってなんぞや まず、コードベースで見ていきます。

clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心

リレーションシップ駆動要件分析(RDRA)とは？ 要件定義において、重要な要素が3つあります。 「網羅性」：システムの目的や、それを実現するための要件が漏れや重複無く定義されている 「整合性」：各要件の整合性が取れている 「表現力」：それぞれの要件が分かりやすく表現されている 複数の人間で共同作業する際にも、網羅性によって要件定義に必要な情報の枠組みが決まり、整合性によって作業の手順が決まり、表現力によって共通認識を確立します。 リレーションシップ駆動要件分析(RDRA)とは、要件定義において重要なこれらの３要素を高いレベルで実現するための要件分析フレームワークです。 RDRAでは要件定義を4つの構成要素に分け、UMLを拡張した表現方法で要件分析を行います。 よくあるように要件をリストでただ並べるのではなく、UMLの視覚効果を利用することで表現力を実現します。 要件定義についてはこちら↓

はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も

質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu

先日ふとSNSを眺めていると、「アジャイル」と「ウォータフォール」はあうあわないがあるので、使い分けるのが吉的な意見を見てなんだかもやっとした気分になった。 正直アメリカに来てから「ウォータフォール」を見たことが無い。確かに日本にいたときは使われていた。最近はさすがに「アジャイル」がだんだん主流になっていく流れも見える気がするが、 アジャイルが「主流」という感じすらしっくりこない。なんでだろう？アメリカでもアジャイルは「主流」ではない。 日本にいたときの個人的な開発方法論のイメージ 日本に居たときは、実際にウォータフォールが沢山あった。ただし、自分はソフトウェア開発には「ウォータフォール」が効率が良いとは一切感じられなかったので、そのことを書いたら結構炎上した。 simplearchitect.hatenablog.com 日本に居る時のイメージは、自分的にはこんなイメージだった。ウォータ

この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき

初めまして、記事に訪問いただきありがとうございますm(_ _)m 今までのプロジェクトでありがちな言い訳。。。 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります なんでこんなことが起こってしまうのか もう15年も前になるPOA vs DOA論争の結果、データ整合性のためにテーブル設計を一番初めに済ませることが一般的になりました。 【初級】ゼロから学ぶDOA　第1回 ですがこのやり方では実際の画面の動きをお客様が見る前に仕様を決めて、 そ

◆「勝手にRDRAを語る夕べ」というイベントとこの記事について connpassに「語る夕べ」というグループがあります。2018/07/18に「勝手にRDRAを語る夕べ」というイベントが開催され、RDRA（ラドラ）という要件定義の手法について語る会が開催されました。 この記事は、そのイベントに私が参加した際のメモと、別の参加者がtwitterで呟いたことをまとめたものです。 ある程度RDRAを知っている人に対して語る会なので、いきなりこの記事を読んでもよくわからないと思います。 「◆参考資料」に記載した資料がRDRAをちゃんと整理して説明しています。RDRAを提唱している神崎さんの資料です。整理された情報が欲しい人はその資料を見て下さい。 この記事は、その資料を見た後で見ると、為になるところが少しはあるかもしれない。。。という記事です。 ◆参考資料 ・RDRA（ラドラ）：Relations

はじめに RDRA2.0を勉強しようと思った理由 ドメイン駆動設計を勉強しているなかで、BIGLOBEさんの取り組みについて書かれた記事の中に、RDRA2.0という設計手法があるということが書かれていました。 なにやらドメイン駆動設計とRDRA2.0という設計手法は親和性が良いとのことなので、RDRA2.0 ハンドブック: 軽く柔軟で精度の高い要件定義のモデリング手法を参考に勉強しました！ 目次 RDRA2.0に取り組むモチベーションとは RDRA2.0とは？ 各レイヤーの概要説明 対象読者 RDRA2.0について知らない人。 要件定義工程で困った経験がある人。 RDRA2.0に取り組むモチベーションとは 設計について抱えている課題 低品質の要件定義資料 要件定義設計書は、機能一覧やユースケース一覧などの大量の設計書を作成する必要がある。そのうえ、大量の設計書全体の整合性を担保しなくてはな

Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ

はじめに こんにちは！ 社会人2年目を頑張っております、エンジニアの@b0ntenmaruです。 今年2月までリファクタリング専門チームにてcrowdworks.jpの技術的負債を返却するために奮闘しておりましたが、そこから現在まではユーザーの皆様に安心安全なサービスを提供するためにクラウドワークス 安心安全宣言のための施策を行っています。 リファクタリング専門チームについては以下をご覧ください。 engineer.crowdworks.jp qiita.com 施策による機能開発を行う際に直面した課題 施策では主にフロントエンドの機能追加をすることになったのですが、技術的負債によりスピードを維持しながら開発を続けることは困難な状態でした。 crowdworks.jpを取り巻くフロントエンドの技術スタックはざっくり書くと下記3つに分類できます。それぞれで発生している問題を簡潔にまとめます。

アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い

皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ！”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。

ドメイン駆動設計(DDD)に関するアドベントカレンダー。DDDに関することであればなんでもOK。 「エリックエヴァンスの」としてないので、ドメインを扱う設計手法であればOKです。実践ドメイン駆動設計でも、CQRS(Event Sourcing), クリーンアーキテクチャとかでもよいですが、必ずドメイン駆動設計にどう関係するか書いてくださいね。 あと、議論のきっかけにできればよいと思いますので、入門的なこと・高度なこと・成功したこと・失敗したこと・改善の余地などハードルは下げますので、自由に書いてください。 推奨ハッシュタグ #ドメイン駆動設計 ドメイン駆動設計 #2 Advent Calendar 2018 もあります！ https://qiita.com/advent-calendar/2018/ddd-2

ダイアグラム別UML徹底活用 第2版 作者:井上樹翔泳社Amazon 目次 目次 はじめに プロジェクトの開始時にやるべきこと ドメインモデル図とは ドメインモデル図を描く手順 1. 「名詞」の抽出 2. モデル同士の関係を線と矢印で表す 3. 中心となるモデルに色を付ける ドメインモデル図を用いる際の注意点 ドメインモデル図の活用方法 ドメインモデル図の作成例 例1. 認証システムの場合 例2. 課金システムの場合 例3. 本屋の場合 例4. 投稿システムの場合 GitHub 参考資料 はじめに ソフトウェアの仕様書、設計書の作成や管理を効率化するために、Markdown + PlantUMLによる作成方法を日々模索しています。 しかしながら、そもそもUML図の正式な書き方というものをちゃんと分かっていないというのが正直なところなので、PlantUMLを通じてUMLの各種図の書き方を勉強

※この記事は著者の増田さんの了解の上で限定公開させて頂いております。 https://twitter.com/masuda220/status/1215122054795522049?s=20 オブジェクト指向、設計がなぜ必要か = ソフトウェア全体の整理整頓をするため 第1章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎている ちょっとずつゴミコードが追加されていった結果 重複しているコードをutil神クラスに押し込むと、あらゆる関心事が集中してしまう 変更に強いプログラムの書き方 メソッドは短く、クラスは小さく 略語は使わない 意味のまとまりで空行をうまく使う 説明用のローカル変数の導入（変更の影響範囲を局所化） 1つの変数に代入を繰り返す破壊的代入を避ける 意味のあるコードのまとまり（段落）を「メソッド