タグ

architectureに関するkomlowのブックマーク (121)

  • Ready for changes with Hexagonal Architecture

    by Damir Svrtan and Sergii Makagon As the production of Netflix Originals grows each year, so does our need to build apps that enable efficiency throughout the entire creative process. Our wider Studio Engineering Organization has built numerous apps that help content progress from pitch (aka screenplay) to playback: ranging from script content acquisition, deal negotiations and vendor management

    Ready for changes with Hexagonal Architecture
  • Data-Oriented Architecture

    There’s a little-known pattern in software architecture that deserves more attention. Data-Oriented Architecture was first described by Rajive Joshi in a 2007 whitepaper at RTI, and again in 2017 by Christian Vorhemus and Erich Schikuta at the University of Vienna in this iiWAS paper. DOA is an inversion of the traditional dichotomy between a monolithic binary and data store (monolithic architectu

    Data-Oriented Architecture
  • マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ - 赤帽エンジニアブログ

    インテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 今回は レッドハットのシニアアーキテクトである Eric Murphy さんによる「マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ(CDC)」の翻訳記事です。この記事では、イベントソーシング、CDC、CDC + Outboxパターン、CQRSをそれぞれ簡単に説明しながら、それらの特性の違いを比較します。また、イベントソーシングとCQRSの簡易な説明がなされている他、あまり明確に語られることが少ないもののソフトウェアの設計に大きな影響をおよぼすドメインイベントとチェンジイベントの違いにも触れられています。 [原文] Distributed Data for Microservices — Event Sourcing vs. Change Data Captur

    マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ - 赤帽エンジニアブログ
  • ソフトウェアアーキテクチャを学ぶために - kawasima

    いわゆるGoFの23個のデザインパターン。知っておくに越したことはないが、フレームワーク・ライブラリに溶け込みすぎていて、現代では知らないうちに使ってることになるので、余裕があれば。

    ソフトウェアアーキテクチャを学ぶために - kawasima
  • Shopifyはいかにしてモジュラモノリスへ移行したか

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    Shopifyはいかにしてモジュラモノリスへ移行したか
  • メールを送信する話 | BLOG - DeNA Engineering

    こんにちは、IT基盤部の中村です。 主に社内システムのインフラを担当しています。 現在の業務内容とは少しずれてしまいますが、最近までメール系のインフラには深く携わっていたこともあり、今回はメールシステムについてお話します。 今どきSMTPなどレガシーな話かもしれませんね。しかしながら良くも悪くも枯れたSMTPはインターネット基盤の根底に位置する息の長い技術でもあります。 きっとみんなまだ使ってるはずなのに、あまりノウハウが出回っていないのが辛いと感じているそこの担当者の方、よろしければ少しの間お付き合いください。 サービスでのメールの利用用途 我々がサービスとしてメールを取り扱うとき、その主だった利用用途は下記の2つです。 メールマガジンなどの情報発信 入会・ユーザ登録時などのユーザ存在確認 メールマガジンはユーザーに情報を新たに届けたり、あらたに弊社の別のサービスに触れて頂く機会を提供す

    メールを送信する話 | BLOG - DeNA Engineering
  • 世界一わかりやすいClean Architecture - nuits.jp blog

    項は「C# Tokyo オンライン「世界一わかりやすいClean Architecture」他」による発表の登壇原稿となります。過去に発表した.NET版の記事はこちらにアーカイブしています。 稿のサンプルコード・PPTはこちらで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 github.com また動画を以下で配信しています。よろしければご覧ください。 世界一わかりやすいClean Architecture はじめに まず初めに、クリーンアーキテクチャの誤解されがちな二つのことについてお話させていただきます。 その上で、クリーンアーキテクチャの質とは何か?押さえておくべき、当に重要だと考えている三つの事について、お話しします。 注意事項 さて題に入る前に、少し注意

    世界一わかりやすいClean Architecture - nuits.jp blog
  • What is Software Architecture? | 8th Light

    I'm sure at some point you've had to draw some boxes and arrows to describe the high level view of how a system works. But what are those boxes and arrows called? We often use terms like microservices, monolith, REST, or event driven, but what are these? As part of my apprenticeship I've been reading about formal Software Architecture concepts and definitions, and throughout this post I'll explain

    What is Software Architecture? | 8th Light
  • Software Architecture Guide

    When people in the software industry talk about “architecture”, they refer to a hazily defined notion of the most important aspects of the internal design of a software system. A good architecture is important, otherwise it becomes slower and more expensive to add new capabilities in the future. Like many in the software world, I’ve long been wary of the term “architecture” as it often suggests a

    Software Architecture Guide
  • DDD 指向マイクロサービスの設計 - .NET

    このコンテンツは eBook の「コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャ」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。 ドメイン駆動設計 (DDD) は、ユーザーのユース ケースに則したビジネスの現状に基づくモデリングを提唱します。 アプリケーションの構築のコンテキストで、DDD は問題をドメインと呼んで論じます。 独立した問題領域のことを境界付けられたコンテキストと言い (境界コンテキストはそれぞれ特定のマイクロサービスに関連します)、共通の言語を使ってこれらの問題を論じることを重視します。 また、内部実装をサポートするための多くの技術的概念とパターンも提案します。たとえば、(ドメイン モデル貧血症ではなく) 豊富なモデルを持つドメイン エンティティ、値オブジェ

    DDD 指向マイクロサービスの設計 - .NET
  • アーキテクチャ大全 - kawasima

    お気に入り / ページネーション / 検討リスト / カテゴリ毎の件数表示 / Conversation threading / オートログイン / 途中保存 / 予約 / 未読管理 / アンケート

    アーキテクチャ大全 - kawasima
  • ソフトウェアアーキテクチャの歴史 - tasuwo's notes

    改めて ソフトウェアアーキテクチャ GUI のアーキテクチャの歴史を調べてみたくなった。来の MVC とは何か?何が正しくて何が間違っているか?も重要なのだが、それよりは、なぜそれが生まれたのか?何を解決しようとしたのか?どのような問題点が生まれて、それをどう工夫して解決・発展してきたのか?を知りたい。しかし、そういうことがまとまっている日語の情報が少ないので、自分で色々かいつまんでメモしておく。 MVC の原点は 70 年代にまで遡り、実装としては Smalltalk-80 のクラスライブラリとして実装されたのが最初だと思われる。しかし、後世に大きな影響を及ぼしたポイントをいくつか持ちつつも、当時のアーキテクチャが現代においてそのまま利用されているケースはほぼないといっていい。したがって、単に MVC といった時には大抵最初期の MVC を指すことは少なく、区別するために最初期の M

    ソフトウェアアーキテクチャの歴史 - tasuwo's notes
  • MemSQL Architecture - The Fast (MVCC, InMem, LockFree, CodeGen) and Familiar (SQL) - High Scalability -

    « Paper: A Provably Correct Scalable Concurrent Skip List | Main | Ask HighScalability: Facing scaling issues with news feeds on Redis. Any advice? » This is an interview with MemSQL cofounder’s Eric Frenkiel and Nikita Shamgunov, in which they try to answer critics by going into more depth about their technology. MemSQL ruffled a few feathers with their claim of being the fastest database in the

    MemSQL Architecture - The Fast (MVCC, InMem, LockFree, CodeGen) and Familiar (SQL) - High Scalability -
  • 実践クリーンアーキテクチャ with Java

    この記事について こちらの記事はクリーンアーキテクチャの Java 実装による解説記事です。 MVC フレームワークに組み込むために一部変更している部分もあります。 それをふまえてご覧ください。 講演内容が @IT さまに記事にしていただけました。 あわせてご参照ください。 https://www.atmarkit.co.jp/ait/articles/1907/08/news002.html クリーンアーキテクチャよりも軽量で無理なく導入しやすいアプリケーションアーキテクチャパターンを考案しました。 https://nrslib.com/adop/ スライド JJUG CCC 2019 Spring での発表資料です。 この発表をするにあたって記事を書くことにしました。 YouTube YouTube でこちらの解説を行いました。 その他解説もしています。もしよろしければチャンネル登録を

    実践クリーンアーキテクチャ with Java
  • How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh

    How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh Many enterprises are investing in their next generation data lake, with the hope of democratizing data at scale to provide business insights and ultimately make automated intelligent decisions. Data platforms based on the data lake architecture have common failure modes that lead to unfulfilled promises at scale. To address these

    How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh
  • ソフトウェア設計が重要である理由 | POSTD

    新しいプロジェクト始まると、開発者はいきなりプログラミングに飛びつく傾向があります。それもいいでしょう。結局、それが仕事なのですから。でも、時には飛びつく前にブレーキをかけて、ソフトウェア設計から手を付けるのもいい考えかもしれません。 “ホワイトボードを使う長袖のホワイトシャツの男性”(出典: Trent Erwin / Unsplash ) ソフトウェア設計にはいろいろな方法があります。UMLなどのモデリング言語のソフトウェアを利用することもできるし、 テキストを書いて 画像を使うこともでき、あるいはホワイトボードに描くこともできます。ここで大切なのは、ソフトウェアの開発中に設計を保存して再考できることです。設計は多少なりとも改善していかなければなりません。ですから、いつも最初からホワイトボードに描きたいというわけではないのならばデジタルデータで、設計を行うのも良さそうです。データの保存

    ソフトウェア設計が重要である理由 | POSTD
  • 思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall

    2. What is Software Architecture ● IEEE1471「コンポーネント、それらの関係や環境、設計やそのコンポーネント、それらの関係や環境、設計やそのそれらの関係や環境、設計やその関係や環境、設計やそのや環境、設計やその環境、それらの関係や環境、設計やその設計やそのや環境、設計やそのその関係や環境、設計やその 進化を左右する原則に具現化されたシステムの基的な構成」を左右する原則に具現化されたシステムの基的な構成」左右する原則に具現化されたシステムの基的な構成」する原則に具現化されたシステムの基的な構成」原則に具現化されたシステムの基的な構成」に具現化されたシステムの基的な構成」具現化を左右する原則に具現化されたシステムの基的な構成」されたシステムの基的な構成」システムの基的な構成」の関係や環境、設計やその基的な構成」な構成」構成」」 ● M

    思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
  • 大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 前編 | POSTD

    バックエンドに関する経験があった私は、2年前にモバイルソフトウェアエンジニアとしてUberに入社しました。担当することになった仕事は、決済機能の構築を含む アプリの刷新 です。その後、 技術管理の側に回る ことになり、チームそのものを率いることになります。配下のチームは、決済を行うバックエンドシステムの多くを担当していたため、責任者となった私もバックエンドに触れる機会が以前にも増して多くなりました。 Uberで働く前は、分散型システムの経験はなきに等しかったと言っていいと思います。 それまでの私は、一般的なコンピュータサイエンスの学位を取得後、フルスタックのソフトウェア開発に10年間、関わっていました。分散型システムについては、一応、大まかな仕組みやトレードオフなどは知っていましたが、一貫性や可用性、冪等性などの概念に精通していたとはお世辞にも言えません。 この記事では、大規模で可用性が高

    大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 前編 | POSTD
  • Goで書くClean Architecture API - Qiita

    Enterprise Business Rules ビジネスルールの為のデータ構造を持ったオブジェクト。 データの実態を表す場所。 Application Business Rules ビジネスルールを操作する場所。 つまりこのアプリケーションで何ができるかを実践します。 Interface Adapter 外部からの入力、データの永続化、表示を担当する場所 Frameworks & Drivers Webフレームワーク、DB操作の実際に担うソース、 フロントエンドUIなどがここに所属しています。 外側のレイヤーの要素を直接参照してはならない 上記の図におけるこの矢印は依存を表しており、 内側のレイヤーから外側のレイヤーの要素への依存を禁じます。 ここでいう依存とは要素(構造体、変数など)への直接参照をさせないということです。 では外側のレイヤー要素を参照せざる得ないは、どうするのでしょ

    Goで書くClean Architecture API - Qiita
  • Model View Controller isn't

    The Model-View-Controller (MVC) pattern is everywhere. Web frameworks use. Apps use it. GUIs use it. Well, actually they don't use MVC. It is just a marketing lie. They use something else like MVA. The History of MVC MVC was invented in the 70s, when Alan Kay with his group worked on the Dynabook and Smalltalk at Xerox Parc. Trygve M. H. Reenskaug remembers it: I created the Model-View-Controller

    Model View Controller isn't