InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版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が最近リリースされ、重要な変...
プロダクト開発でドキュメントを書かないとどうなるか
Agile Manifestoには以下のように書いてあります。 動作するソフトウエアは包括的なドキュメントにまさる ともするとドキュメント軽視と取られかねない宣言です。この宣言を誤って解釈してドキュメントはいらないとなる場合もあるかもしれませんが筆者はそれは間違いだと思っています。この宣言では包括的なドキュメントよ
Firebaseの存在をフロントエンドから隠蔽するために
「Firebase は安いし楽だしマジ最高」という一心で技術選定してしまったプロダクトが成功して見えてきた課題、割高なコスト・権限管理・カスタマイズ性、そして （特性やスキルセット的に）RDB 製品が適していたのに無理やり Firestore を採用したことによるデータ不整合。 その結果チーム内で Firebase を抜ける機運が高まるも、Firebase べっとりなアプリケーションすぎて移行しづらいといった問題に出会うかもしれません。 そのような場合に備え、Firebase の存在を隠蔽して開発することに挑戦してみましょう。 注意: Firebase を剥がしているときに「俺、次は絶対そうするわ」と感じたものを書いているだけであり、まだ実際にはこのパターンでプロダクション導入していません。 あくまで個人開発で試してみていけそうと思ったので、提案しますという体です。 また Firebase
A guide to writing specs toward engineers(Japanese)
This slide is for Product Managers who want to write specs that can get buy-in from engineers and that is well stated that a team can start working on i…
ゲームの仕様書を書こうまとめ
ゲームの仕様書を初めて作成する人のための足掛かりのスライド ▼以下のスライドを一つにまとめました ・ゲームの仕様書を書こう１ 仕様書作成の分業とリストの作成 https://www.slideshare.net/ChizuruSugimoto/ss-173331109 ・ゲームの仕様書を書こう２ 仕様書に記載する機能内容 https://www.slideshare.net/ChizuruSugimoto/ss-173332578 ・ゲームの仕様書を書こう３ 仕様書に記載するデータと画面 https://www.slideshare.net/ChizuruSugimoto/ss-173333150 ・ゲームの仕様書を書こう４ 仕様書作成で楽をするconfluenceの活用 https://www.slideshare.net/ChizuruSugimoto/confluence-17333
設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita
/// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>
なぜオブジェクト指向は難しいのか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事の内容 この記事は「オブジェクト指向と10年戦ってわかったこと」という記事を書いた筆者が2年の時を経て「なぜオブジェクト指向は難しいのか」をテーマに、さらなるオブジェクト指向の理解を目的として、通常とは異なるアプローチでオブジェクト指向を解説したものです。 自然言語の限界 人は様々な物事に名前を付けて分類します。リンゴには「リンゴ」、車には「車」という名前を付けて分類、認識しています。そして車には「走る」という役割があり、それらの役割もまた名前をつけて分類し、認識しています。 しかし、このように自然言語を使って物事を識別している
オブジェクト指向と10年戦ってわかったこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事の内容 オブジェクト指向は難しい！わかった気になって実践すると詰みます... ｳｷﾞｬｰ この記事は10年以上オブジェクト指向と戦った筆者が、通常とは異なるアプローチでオブジェクト指向を解説したものです。 筆者はJavaを使って本格的なシステム開発をしたことがありませんが、オブジェクト指向言語として最もポピュラーなJavaをベースにオブジェクト指向について解説させていただきました。 また、この記事の続編にあたります「なぜオブジェクト指向は難しいのか」を更に2年の時を経て執筆させて頂きました！是非こちらも一読していただけると嬉しい
プログラム入門：抽象化の話
プログラムの入門としての抽象化の話をします。ベテラン向けじゃないんで、ベテランの人は読んでも新しい事は無いと思います。 データ分析界隈だと、数学や物理などで抽象的な事というのには良く出会ってきた経験を持つので、抽象的な物は得意な方だ、という人は多いと思うし、実際そうだと思う。 ただ、プログラムの抽象化は違う部分もあるので、一度プログラムの抽象化という物を初心者の気持ちになって学んでみる機会は必要とも思う。 ここではそんな話をしてみる。 カプセル化 プログラムの抽象化と言えばカプセル化なのだが、いまいち良い解説が無いので自分で書く事にする。 一般的な事は知らないけれど、プログラムにおいては、抽象化の定義は「情報を落とす」事となっている。 全ての情報を持っている所から、特定の情報だけにする事でアクセスする「口」を定める訳だ。 だからだいたいの抽象化は物を「削る」のだけど、一つだけ例外がある そ
画面遷移図の作成方法ついてのまとめ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事は、アプリケーション開発におけるUI設計の、画面遷移図について個人的に考察したものです。画面遷移図を作る上で、現状どのような選択肢があるかをまとめています。正直調べ足りないところも多々ありますので、内容が偏っていたり間違ってる可能性があります。参考にする場合はご注意ください。 画面遷移図の役割 画面遷移図とは、画面とその移り変わりを図にしたものです。画面同士を矢印などでつなぎ、矢印の方向に画面が遷移することを表したりします。 最近はUI設計の成果物として、実際に画面遷移の操作をできるモックアップの開発も盛んになっていま
UIデザインのバグを減らすための施策
UIデザインにもあるバグ 今年の WWDC 2019 で印象に残っているセッションのひとつが「Introducing SwiftUI: Building Your First App 」。SwiftUI は開発がよりスマートにできるようになるだけでなく、デザインツールの新しい可能性を示しているように見えました。SwiftUI はとてもエキサイティングですが、個人的に刺さったのが上の写真。改めて意訳した図を作りました。 UI デザインは単に理想型を作れば良いのではなく、様々な状態（ステート, State）を考慮する必要があります。情報量に応じてどう見せるかだけでなく、様々な種類のエラーにどう対応するか考えなければいけません。How to fix a bad user interface で紹介されている UI Stacks のように、少なくとも 5 つのスクリーンデザインが必要になります。
新しいフレームワークを学ぶならTodoMVCではなくRealWorldを参考にしよう - Runner in the High
よく新しいフレームワークを学ぶにはTodoアプリを作ってみるのがよい、と言われる。実際、Todoアプリを様々なフレームワークで作ってみたサンプルをまとめたサイトもあったりする。 ところが、実際に業務で作るようなアプリケーションはTodoアプリの範疇を超えている。とくにSPAにもなると、画面遷移やWebAPI連携、大規模な状態管理などなどの条件が増えるので、Todoアプリを作っているときには考慮できていなかった大変さが出てくる。 そこで参考になるのが RealWorld example apps と呼ばれるプロジェクト 端的に言うと、TodoMVCの大規模版。 規定のスペックに沿って、様々なウェブフレームワークで作られたアプリケーションのリポジトリがリストアップされている。 スペックについて "Conduit" is a social blogging site (i.e. a Medium
Software Architecture Patterns
Get full access to Software Architecture Patterns and 60K+ other titles, with a free 10-day trial of O'Reilly. There are also live events, courses curated by job role, and more. Chapter 1. Layered Architecture The most common architecture pattern is the layered architecture pattern, otherwise known as the n-tier architecture pattern. This pattern is the de facto standard for most Java EE applicati
オブジェクト指向がn%理解できる記事まとめ
全部読めばきっと理解できる…はず。 話題編 オブジェクト指向が5000%理解できる記事 理論編 オブジェクト指向を5000%理解できたら、次に5000兆%理解できように実社会の例でオブジェクト指向を考えてみる。 オブジェクト指向が5％くらい理解できればいいなという記事 魔法のように理解しようとするオブジェクト指向 オブジェクト指向プログラミング（OOP）がちょっとわかるようになるための記事 C#のオブジェクト指向が全く理解できないのでまとめる記事 Listもどきでほんわか理解するオブジェクト指向 カプセル化編 オブジェクト指向設計とは? オブジェクトの「クラス」とかいう言葉の自分なりの理解 分かりそうで分からない少し分かるオブジェクト指向プログラミング vs 関数型 オブジェクト指向と関数型についての自分の考え オブジェクト指向と関数型プログラミングを100‰説明する記事 実践編 オブジェ
やさしい機能仕様 パート1: なぜわざわざ書く必要があるのか? - The Joel on Software Translation Project
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/2 ジョエル・テストを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければならないということだった。仕様書はデンタルフロスみたいなもので、みんな書かなきゃいけないと思ってはいるが、誰も書かない。 なぜ人々は仕様書を書きたがらないんだろう? 人々は仕様書作成フェーズを飛ばせば時間を節約できると主張している。彼らは仕様書作成がNASAのスペースシャトルのエンジニアか巨大な保険会社で働いているような人たちのための贅沢品であるかのように振舞っている。戯言だ。何よりも仕様書を書かないというのは、あなたがソフトウェアプロジェクトに持ち込む、最大かつ不必要なリスクである。それは着替えだけリュックに詰めて、その場になれば何とかなることを期待してモハーベ砂漠の横断に出発するのと同じくら
アプリクライアントがリソース指向なサーバAPI設計に期待すること - Qiita
酔いどれ設計ナイト2019 - connpassの発表資料です。 イベントのテーマ 「DB設計とAP設計をつなぐナニカ」 ということでこの記事では、アプリケーションサーバの利用者であるクライアントの視点から、どういう構造が嬉しいのか語ります。 自己紹介 iOSアプリ設計パターン入門という本の前半で、「設計とは何か」という主語の大きい話をしたり、GUIアーキテクチャの40年の歴史をまとめたりしました 題材をSwiftに絞っただけで、内容としては他プラットフォームにも通用する感じのやつなのでよかったらおひとつどうぞ Qiitaだと、お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える - Qiitaという記事がよく読まれてます 議論の前提 今回の議論にはいくつかの前提があります。 クライアントチームとサーバチームが充分に協調し
メモ：ドメイン駆動設計におけるモデルの効用と、モデルが満たすべき3つの基本的用法(私訳) - HITORIGOTO
日本語版『エリック・エヴァンスのドメイン駆動設計』p.3の、「ドメイン駆動設計におけるモデルの有用性」の部分、大事なことを言っているような箇所なのに、文章のつながりや意味がイマイチとれなかった。そこで原著Kindle版を購入し、原文から自分なりに訳してみた。（私の訳文は若干補足的な文章になっている） なお、この箇所は見出し（効用/有用性）と、中の箇条書きの構造とがマッチしていないので読みづらいのだと思う。各箇条書きの最初の文が「基本的使用方法」、つまり、モデルに求める条件となっていて、それを満たすとどのようなありがたいことがあるのか（＝効用/有用性）の説明が続く、という構造なのだと思う。 The Utility of a Model in Domain-Driven Design ドメイン駆動設計におけるモデルの効用 In domain-driven design, three basic
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hooks時代の設計の話 #agrinoteinside
あの日見た M V Whateverの Modelを僕たちは まだ知らない
Software Architecture Patterns [Book]