TypeScriptでSOLID原則〜依存性逆転の原則〜 | メンバーズエッジカンパニーブログ
2021/09/29 TypeScriptでSOLID原則〜依存性逆転の原則〜 design TypeScript SOLID原則とは？ SOLID原則とは、オブジェクト指向プログラミングにおいて、変更しやすい・理解しやすい・再利用しやすいモジュール（クラスや関数などの、ソフトウェアのを構成する部品）を設計・開発するための原則のことです。ソフトウェアエンジニアRobert C. Martinに提唱された多くの設計原則を5つにまとめたものの頭文字をとって命名されました。 S … Single Responsibility Principle: 単一責任の原則O … Open-Closed Principle: 開放閉鎖の原則L … Liskov Substitution Principle: リスコフの置換原則I … Interface Segregation Principle: インター
GoでCRUDアプリをMysql、GORM、Echo、Clean Architectureで作る - Qiita
目次 Clean Architectureとは Clean Architectureというと、以下の図が大変有名です。 Clean Architectureの目的は関心の分離で、 これを達成するために意識すべきことが各レイヤーの依存性です。 関心の分離によりコードの可読性が向上したり、変化に強い設計になります。 この辺のメリットやClean Architectureの詳細に関しては参考記事に載っていますのでそちら参照ください。 上記の図では、円の外側から内側に向かって矢印が向けられていますが、これが依存の向きで、 外側から内側への依存は可能ですが、内側から外側は不可能です。 言い方を変えると、内側で宣言したモノを外側から呼ぶことはできますが、外側で宣言したモノを内側から呼ぶことはできないという話です。 この記事では依存の向きに注意しながら コードを紹介していきます。 各機能に関して 各機能
Go言語とClean ArchitectureでAPIサーバを構築する - Qiita
Clean Architectureとは Clean Architecture(クリーンアーキテクチャ)とは，レイヤに内側と外側の関係性を持たせるアーキテクチャである． 「外側のレイヤは内側のレイヤだけに依存する」というルールを守ることによって，アプリケーションから技術を分離することが目的である． アプリケーションから技術を分離すると何が嬉しいのか ここでの「技術」とは，HTTPやcsv，MySQLなどのことを意味している． アプリケーションから技術を分離すると，技術を容易に変更できたり，テストコードを書くときに容易にモックできたりする． 例えば，出力をHTTPからcsvに変更したくなったときなどに容易に変更が可能である． 各レイヤの責務 Clean Architectureで提案されているレイヤ構造は以下の画像のようなものである． 内側から，Entitiesレイヤ，Use Casesレイ
個人開発でクリーンアーキテクチャを導入してみた
モチベと本記事の軽い概要 個人開発でクリーンアーキテクチャを採用してみました。理由としては私の師匠(@yuyaさん(twitter))にクリーンアーキテクチャを勧められて、ボブおじさんことRobert C.Martinの書籍を読みはじめたことがきっかけでした。正直私の読解力では読んだだけでは理解できず、手を動かしてみようと思ったことが大きいです。 対象読者 クリーンアーキテクチャについてはもう知っている方 目次 クリーンアーキテクチャとは(超簡単に) 実際採用してみた感想 Goでの実装例 クリーンアーキテクチャとは 詳しい説明はまた別で書きたいと思います。 関心の分離、疎結合を提供し、より変化に強いソフトウェアを提供することを目指したアーキテクチャです。 個人的には、依存を一方通行に(外から内方向)するというのが一番のミソだと思ってます。 参考にした文献等 クリーンアーキテクチャを採用して
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
AWS Well-Architected – 安全で効率的なクラウドアプリケーション
AWS Well-Architected は、クラウドアーキテクトがさまざまなアプリケーションやワークロード向けに高い安全性、性能、障害耐性、効率性を備えたインフラストラクチャを構築する際に役立ちます。AWS Well-Architected では、6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいて、お客様とパートナーがアーキテクチャを評価し、スケーラブルな設計を実装するための一貫したアプローチを提供しています。 AWS Well-Architected Framework には、ドメイン固有のレンズやハンズオンラボ、そして AWS Well-Architected Tool が含まれています。追加コストなしで AWS マネジメントコンソールで利用できる AWS Well-Architected Tool は、ワークロードの定期
[翻訳記事]マイクロフロントエンド - マイクロサービスのフロントエンドへの応用
モダンな Web アプリを異なる JavaScript フレームワークを使う複数チームで開発するためのテクニック はじめに この記事は翻訳記事です。 原著者の許可をとって翻訳・掲載しています。 原文はこちらです。 翻訳者 マイクロフロントエンドとは？ マイクロフロントエンドという言葉は 2016 年の終わりにThoughtWorks Technology Radarで言及されました。 それはマイクロサービスの考え方をフロントエンドに拡張したものです。 現在の Web のトレンドは多機能でパワフルな SPA です。 SPA はフロントエンドとバックエンドを切り離すという、マイクロサービスの考え方に基づいています。 開発をすすめていくと、特に複数のチームで管理している場合 フロントエンド層が肥大化して管理が難しくなりがちです。 これを「モノリシックなフロントエンド」と呼びます。 マイクロフロン
マイクロサービス化を進めていたが、切り戻してモノリスで開発しているお話 - STORES Product Blog
はじめに この記事はhey Advent Calendar16日目の記事です。 STORES 予約 開発チーム @arrow_make です。 昨年度まで進めていたマイクロサービス化を止めてモノリスで開発するに至った過程について書いていきます。 STORES 予約 におけるマイクロサービス化 STORES 予約 には主に、管理画面(予約サイト管理者向け)と予約者画面(予約をするエンドユーザー向け)の2種類の画面があり、バックエンドのRailsサーバーでは両方の画面に向けたAPIを提供しています。 その中で主にチーム内でapi/v2と呼んでいる予約者画面に向けて提供しているAPIに連なる機能群を、Railsから切り離して一つのサービスとして独立させることを目的として始まったものと認識しています。 私自身は、マイクロサービス化の走り出し時にはまだ在籍しておらず、入社後すぐにこのプロジェクトに途
Clean Architectureなにもわからないけど実例を晒して人類に貢献したい - エムスリーテックブログ
こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 これまでは、中村の記事で宣言した 「医師版Stack Overflow」(12/16に正式名称Docpediaとしてリリースされました) の技術的チャレンジの 記事を続けて書いていたのですが、今回はここで宣言しなかったClean Architectureについて書きます。 浪江駅（なみええき）は、福島県双葉郡浪江町にある、東日本旅客鉄道（JR東日本）常磐線の駅。本文には特に関係ありません。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘出版社/メーカー: ドワンゴ発売日: 2018/08/01メディア: Kindle版 なぜ書くのか 参考にできる実例を増やしたい Tech Blogはそのままドキュメ
せめてリポジトリの各ディレクトリの概要説明だけでも欲しい思ったので dirmap というツールを作ってみた - Copy/Cut/Paste/Hatena
既存の開発に参加するときや、0->1の開発をしているとき、いつも「せめてリポジトリの各ディレクトリの概要説明だけでも欲しい」と思っていました。 既存のプロジェクトに参加するときは「プロジェクトの理解をする側」、0->1のプロジェクトで開発をしているときは「説明をする側の立場」で、です。 Ruby on Railsのような基本のディレクトリレイアウト決まっていてもそのプロジェクトの独自性がでてきますし、Goのようにスタンダードなレイアウトがないのであればなおさら初見ではわかりません。 「じゃあREADME.mdにでも書いておけばいい」というのはその通りです。 ただ、概要説明であっても一度書いたら終わりではなく、更新は必要になります。特に0->1のプロジェクトの初期ではディレクトリレイアウトすら途中で変わるということはままあります。 （ここらへんは「継続的ドキュメンテーション」として私の興味の
CRISP: Critical Path Analysis for Microservice Architectures
You’re seeing information for Japan . To see local features and services for another location, select a different city. Show more Uber’s backend is an exemplar of microservice architecture. Each microservice is a small, individually deployable program performing a specific business logic (operation). The microservice architecture is a type of distributed computing system, which is suitable for ind
Welcome
Context Mapper is a modular and extensible modeling framework for Domain-driven Design (DDD) and its strategic patterns. The core component provides a DSL to create context maps featuring these DDD patterns. The model behind the language and its semantic rules express our interpretation of the DDD patterns and how these patterns can be combined in a concise and consistent manner. At present, Conte
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Infrastructure as Code: the next big shift is here
Complete Guide to Monolithic vs. Microservices Architecture