Design Doc の書き方 / How to Write a Design Doc (Ja ver.)「Design doc とは何か」・「何を書けばよいのか」を説明するスライドです。 関連するプレゼンテーション「読みやすいコードの書き方」: https://gist.github.com/munetoshi/65a1b563fb2c271f328c121a4ac63571 © 2023 Munetoshi Ishikawa, supported by LINE corporation
【メモ】良いDesign Docs(Software Design Document)を書くためのリソース集
自分が良い Design Docs(Software Design Document)を書くために、読んだ/参考になったリソース集 一覧 Design Docs とは Design Docs at Google デザインドック(Design Doc)について デザインドックで学ぶデザインドック 残業も減らせる!? 上級エンジニアになるための Design Doc 超入門 「Design Doc」って何なのか？ What Is A Design Doc In Software Engineering? (full example) What is a Design Doc: Software Engineering Best Practice #1 https://github.com/kaiinui/note/blob/master/Design--Designdoc.md Googleの
フロントエンドエンジニアが変える現場のモデリング意識/modeling-awareness-changed-by-front-end-engineers
フロントエンドエンジニアが変える現場のモデリング意識/modeling-awareness-changed-by-front-end-engineers
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
シンプルなテキストファイルで UML が書ける、オープンソースのツール
🌱 一目でわかるPlantUML 🚀 はじめに PlantUMLは、様々なダイアグラムを迅速かつ簡単に作成できる、非常に多目 的なツールです。 シンプルで直感的な言語を利用することで、ユーザは様々なタイプのダイアグラム を簡単に作成することができます。 この言語の機能とシンタックスの詳細については、PlantUML Language Reference Guide をご参照ください。 PlantUML を初めてお使いになる場合には、 を素早く立ち上げて実行するために、クイック・スタート・ ページから始めることをお勧めします。 さらに、PlantUML は、ワークフローを強化するために、他のさまざまなツールと シームレスに統合することができます。 🧩 サポートされる UML 図 PlantUML を使用することで、以下のような構造化された UML 図を作成することができます： シーケン
一対一関係のテーブル設計
一対一の関係のデータは一つのテーブルにまとめるというのが、データベース設計のセオリーです。ですので、特別な事情が無い限りは一対一関係のテーブルを作るメリットはないです。ただ、絶対に一対一の設計はNGというわけでもありません。 一対一の関係が必要な特別な事情の例と、その場合の設計法や注意する点について、今回は取り上げます。 難易度:
新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの？」 という
![新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/da075520c5346bf5227bf90557a35ccf8b5b07ae/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20181210%2F20181210195849.png)
設計/コードレビューで"常に"心がけるポイント - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
React Componentの実装ルールを決めてみた - Money Forward Developers Blog
こんにちは。 経費精算サービス「マネーフォワード クラウド経費」の開発チームでフロントエンドエンジニアをしている坂本です。 クラウド経費ではJSのライブラリとしてReactを採用しているのですが、最近クラウド経費で React Component を実装する際のルールをまとめたので、その話を書こうと思います。 なぜルールをまとめようと思ったのか Componentの分割ルールとしてAtomic Design、スタイルの管理としてstyled-components、GraphQL用のライブラリとしてApollo Clientを導入し実装を進めています。 昨年の10月までは挙げた３つとも使用していなかったので、試行錯誤しながら進めています。 チームメンバーの各々が試行錯誤しながら実装を進めていくので、最近はチーム内で認識の齟齬や持っている情報に差が出るようになりました。 そこで一旦現状を整理し
履歴テーブルについて - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
Presentational and Container Components
BismuthUpdate from 2019: I wrote this article a long time ago and my views have since evolved. In particular, I don’t suggest splitting your components like this anymore. If you find it natural in your codebase, this pattern can be handy. But I’ve seen it enforced without any necessity and with almost dogmatic fervor far too many times. The main reason I found it useful was because it let me separ
真偽値の判定に、tinyint(1)を使うか、bool,boolean型を使うか、bit(1)を使うか、enumを使うか - ぽひゅっとメモ
MySQLレベルでの話。 最近SQLの細かい挙動とか、しっかり把握しきれてないなーとか、 一度覚えたことが年が経ってあやふやになってるところが多くある。 また勉強し直したい。 RDBMSとうか、KVSだのNoSQLだのDBのシステムによって大きく違うと思うけれど、 私はMySQLとちょっとPostgreSQLとかSQLiteとか触ったくらいなしょっぱい男です(先の言い訳)。 主に扱うのはMySQLで、そのくらいしかついていけません(わかるとは言いません)。 「MySQLってそうなんだ〜。Oracleだとこうなんだよー、きゃははー」とか言われても、しょんぼりとしかしません。 本題。 Rails使ってると、マイグレーションファイルでDBのテーブル定義して、 rake db:migrateでマイグレーションファイルを元にテーブルが作成されちゃう。 ここで使うDBによって、うまいこと作られる型に差
コンセプトから学ぶAmazon DynamoDB【Amazon RDSとの比較篇】 | DevelopersIO
よく訓練されたアップル信者、都元です。AWS上のシステム設計において、どんな時にRDSを選択するのか、そしてどんな時にDynamoDBを選択するのか。比較しながら見て行きたいと思います。 RDBとNoSQL ACIDなRDB 一昔前、一般的に「データベース」と言えば、多くはリレーショナルデータベース（RDB）のことを指していました。テーブルと呼ばれる「行とカラムで構成される二次元のデータ構造」に対して、SQLと呼ばれる強力なクエリ言語で操作を行い、データの一貫性（Consistency: どこから観測しても同じ値が得られること）や操作の原子性（Atomicity: 一連の操作を全て適用commitするか、全てキャンセルrollbackするかの二択として実現できること）を実現するモデルは、開発者を含むシステムの利用者にとって非常に理解しやすく、広く受け入れられて来ました。多くの方がご存知の通
note・CXO深津貴之はなぜ華麗なキャリアチェンジを続けられるのか？ 技術トレンドと一緒に“廃れない”エンジニアの条件 - エンジニアtype | 転職＠type
転職・求人情報サイトのtype エンジニアtype 働き方 note・CXO深津貴之はなぜ華麗なキャリアチェンジを続けられるのか？ 技術トレンドと一緒に“廃れない”エンジニアの条件 2018.12.25 働き方 時代の変化の中、技術革新は続き、そのトレンドもどんどん変化している。2017年には「Flashが2020年で終了する」というニュースが流れ、各方面に大きな衝撃を与えたことは記憶に新しい。エンジニアのキャリアにおいて、「いかに世の流れを読み、移り変わる技術をモノにしていくか」は重要なポイントと言えるだろう。 そんな中、“華麗なキャリアチェンジ”をした良い例として、BASEのえふしんさんは『エンジニアtype』の取材で、株式会社THE GUILD代表であり、『note』などのサービスを運営する株式会社ピースオブケイクのCXOを務めている深津貴之さんの名前を挙げた。 ＞＞「マークアップエ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
system-design-primer/README-ja.md at master · donnemartin/system-design-primer