タグ

設計に関するgrakuのブックマーク (9)

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

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

    簡単にできるDDDのモデリング - ドメイン駆動設計 - little hands' lab
  • TypeScript * GraphQLのバックエンド設計プラクティス

    2冊目も公開中なのでみてください! https://zenn.dev/tatta/books/4e993c596e7dc9 TypeScriptを使いはじめて1年になるので、バックエンドのWebアプリを設計するときに気を付けていることをまとめました。(※社内勉強会用資料の公開版です。) TypeScriptについては、Next.jsを中心にフロントエンドに関する公開情報が豊富です。一方でバックエンドに関する公開情報が少ないと感じています。(かくいう私もNext.jsからTypeScriptデビューしたわけですが) TypeScript * GraphQL という構成は仕事趣味で採用されている方も多いのではないでしょうか? 私もその1人です。私のような方のためにも、バックエンドの設計プラクティスについてまとめようと思い筆を取りました。 書がこれから始める読者にとっては教科書のようになり、

    TypeScript * GraphQLのバックエンド設計プラクティス
  • 業務でどれだけSQL力がつくのか ~SQLアンチパターンを用いて確認~ 前編

    はじめに こんにちは。 GMOアドマーケティングのKONCEです。 新卒で入社し、数年経ちました。日々の業務で学ぶことは多いですが、今年度は技術の深堀りをテーマにやっていきたいと思っています。 今回は入社してDBSQLに関しては業務内で学ぶことが多く、特別訓練をしていたわけではなかったのですが、「SQLアンチパターン」を用いて学びながら、改めて自分の現状を見つめ直していけたらと思います。 今回は学習を行う側面と自分自身のレベルについて見直していきたいので 知っていた → ○ 部分的に知っていた → △ 知らなかった → × を付けてみようと思います。 目次 SQLアンチパターンについて Ⅰ部 データベース論理設計のアンチパターン 2-1. [○]1章 ジェイウォーク(信号無視) 2-2. [×]2章 ナイーブツリー(素朴な木) 2-3. [○]3章 IDリクワイアド(とりあえずID) 2

    業務でどれだけSQL力がつくのか ~SQLアンチパターンを用いて確認~ 前編
  • ソフトウェア設計の Why & What & How | Wantedly Engineer Blog

    こんにちは、開発チームのアーキテクトをやっている竹野(@Altech)です。先日、新人研修でソフトウェアの設計について話す機会がありました。 ソフトウェアの設計というのは関連する領域が広いため、どうしても断片的な理解になりがちです。そこで、早い段階で全体像を感じてもらうために、ソフトウェア設計の Why と How と What を1時間でまとめて話すというちょっと意欲的なコンセプトで研修を行いました。今回は、その内容を記事にしました。 この研修のねらいはじめにソフトウェアの設計について書かれた情報は世の中に多いですが、その情報の多くは How であり、それだけを読んで適切に使うことが難しいと感じています。その直接的な理由は、How に対しての What、How / What に対しての Why が語られることが少ないからです。 ただ、How だけを知っていると、それは当に問題を解決して

    ソフトウェア設計の Why & What & How | Wantedly Engineer Blog
  • マイクロサービス時代のセッション管理 - Retty Tech Blog

    この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神(注・人名であり実名です)」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、

    マイクロサービス時代のセッション管理 - Retty Tech Blog
  • WEB アプリケーション設計入門 / Introduction to web application design

    PHP Conference Japan 2020 トーク前提の資料です。そのため、トークがないと理解が難しいかもしれません。 https://youtu.be/UTKJ-Lgn3aI?t=36 ※冒頭音声が小さいです。マイクを手に持ってから聞こえやすくなると思います。 資料中の ADOP については下記を参照ください。 https://nrslib.com/adop/ # Abstract https://fortee.jp/phpcon-2020/proposal/da5b9d99-e5a6-4f51-adea-1f1c10d99020 # Ref https://github.com/nrslib/scrum-app-sample-php https://github.com/nrslib/repository-support-php # URL Togetter: https://

    WEB アプリケーション設計入門 / Introduction to web application design
  • 要件定義~システム設計ができる人材になれる記事 - Qiita

    はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの?」 「要件定義ってなに?」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に4つも壁が存在するのです。 そのため、記事では実装(プログラミング)を開始する前に必要となる、 『企画~設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装(プログラミング)に使用する時間

    要件定義~システム設計ができる人材になれる記事 - Qiita
  • 要件定義~システム設計ができる人材になれる記事 - Qiita

    はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの?」 「要件定義ってなに?」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に4つも壁が存在するのです。 そのため、記事では実装(プログラミング)を開始する前に必要となる、 『企画~設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装(プログラミング)に使用する時間

    要件定義~システム設計ができる人材になれる記事 - Qiita
  • それはYAGNIか? それとも思考停止か?

    DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。 Read less

    それはYAGNIか? それとも思考停止か?
  • 1