ソフトウェアデザインにおける構造設計を実践！マネーフォワードさんとワークショップを開催しました｜Goodpatch Blog グッドパッチブログ
Goodpatchでは、UIの構造設計を重視したデザインプロセス「モデルベースUIデザイン」を推進しています。最初にコンセプト定義やユースケースを定義し、情報整理をして最終的に機能やビジュアルなどの具体的なところを詰めていく考えをとっていくプロセスです。 今回は、マネーフォワードさんと「デジタルプロダクトのUI設計のプロセスと考え方を学び、実践することでスキルのベースを身につけること」をテーマに、モデルベースUIデザインについて理解・実践するワークショップを開催しました。本記事では開催の背景から当日の様子をご紹介します。 参加いただいたマネーフォワードのUI/UXデザイナーさんによるnoteもぜひご覧ください！ マネーフォワードがGoodpatchさんとUIデザインワークショップを実施しました！ ご相談いただいた背景 「お金を前へ。人生をもっと前へ。」をミッションに掲げる株式会社マネーフォ
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
エンジニアはどうDDDと向き合っていけばいいのか(1):ChatWork株式会社テックリード加藤さんインタビュー | Tech Direct BLOG
今回はChatWork株式会社のテックリードでいらっしゃいます加藤潤一さんです。 少し技術的な内容になりますが、ドメイン駆動設計(以下 DDD)・リアクティブシステムといった話を中心にお伺いしました。 DDDを適用しやすいソフトウェアとは 愛宕 最初はやはりまずDDDについてお伺いしたいと思います。DDDというと、エリック・エヴァンスのドメイン駆動設計という本が有名です。その肝心な部分としてはソフトウェアエキスパートである開発者も、ドメインエキスパートと一緒にユビキタス言語を作りながら対象の問題を分析・設計していきましょうというようなものだと思うのですが、少し疑問があります。DDDを適用しやすいソフトウェアとそうでないものはあるのでしょうか？ 加藤 基本的にプログラミング言語の制約はほとんどないと考えていますが、最初に考えたいことは、費用対効果に見合うかどうかを考えたいですね。システムの開
2007-03-02
いちばんインパクトがあったのが、T字形ER手法はやっぱりサロゲートキーを認めていないとわかったこと。 「コンピュータの内部で勝手に取った連番は、いちばん手に負えない」とのこと。 何が問題かというと「そういうものがあると、組織変更の時とかに大変なことになる」のだそうだ。何で？て話。 で、休憩時間に質問に行ったわけだ。「サロゲートキーがあるとコード体系の変更に強くなるんじゃないんでしょうか」と。 正美氏の答えはこう： ダメなコードからはダメな構造しか出てこない。 ダメなコードに別名を付けてみてもダメな構造は変わらない。 構造を変えないと。 「サロゲートキーは構造の問題を温存する働きをするだな」「サロゲートキーが邪魔になってシステムに実装できなくなる『外界の変化』というものがあるのだな」と。 http://d.hatena.ne.jp/tgk/20070228#1172679908 うーむ、問題
DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
あってはならない「確実に」という作業指示 プリウスに見るゴムホースの「組み付け基準」 | JBpress (ジェイビープレス)
本来のトヨタ生産方式を説くために始めた「本流トヨタ方式」の本コラムは佳境に入り、「ジャストインタイム」に並ぶ2本柱の1つである「自働化」の話に入って今回は13回目になります。 前回は、トヨタでは自動車生産の最終工程である組み立てラインを品質保証の決め手とするために、「異常があったらラインを止めて直し、次工程に渡さない」という生産体制を作り上げたという話をしました。 これは、豊田佐吉翁が発明したG型自動織機の「機械の自働化」に対比して、「作業者集団に対する自働化」という意味を込めて「もう1つの自働化」（通称「呼び出し紐方式」）とも呼ばれます。 さて、前回は乗用車組み立てラインが舞台でしたが、今回はもっと一般的な「作業指示のやり方」についてお話しします。 ゴムホースの差し込み方は人によって様々 以下の写真は、エンジンと車体をつなぐゴムホースの模型です。直径10ミリ、長さ125ミリのゴムホースで
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
.NETの例外処理 Part.1 - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
Archived MSDN and TechNet Blogs 2/7/2020 2 minutes to read MSDN and TechNet blog sites have been retired, and blog content has been migrated and archived here. Archived blogs are grouped alphabetically by the initial letter of the blog name. Blogs and blog posts can be searched by their names, using the Search box at the top of the page. Actively updated blogs have been moved to other blog sites,
ITアーキテクトの「やってはいけない」：ITpro
ITアーキテクトが知っておくべきアンチパターンを徹底解説 情報システムのアーキテクチャや実装方式を決定するITアーキテクト。データベースやネットワーク，プラットフォームなど，さまざまな技術分野の知識を持ち，全体最適でシステム開発を成功に導かなければならない。しかしそこには，つい陥りがちな「やってはいけないこと」（アンチパターン）が，数多く潜んでいる。そこでここでは，ITアーキテクトが知っておくべきアンチパターンを解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル3～レベル1の3段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■機器増設編 ■業務分析編 ■Windows 7編 ■Android/iPhone編 ■プライベートクラウド編 ■パブリッククラウド編 ■次世代DB編 ■運用管理編 ■プラットフォーム編 ■セキュリティ編
工数管理
プロジェクトを成功させる上で、重要なのは、工数管理です。工数を正確に見積もり、スケジューリングし、また機能追加や修正要求に対して適切に対応することです。不確定な要素が多い中で、プロジェクトを期間内に成功裡に終わらせるのは、奇跡に近いものがあります。 プロジェクトの失敗の多くは、工数管理ができていないことにあります。 客が時間を取れずに要件がまとまらない 頻繁な仕様変更・機能追加 工数の過小評価 無理なスケジュール 仕様のバグ 設計ミス 拡張性のない設計 実装方針ミス 要員のスキルの低さ 無理な要件（性能要件など） など、プロジェクトの進捗を妨げる多くの要因があります。 工数の過小評価 なかでも、工数の過小評価は重大なものです。見積もりの段階ではざっくばらんに見積もってしまうため、実際プロジェクトが始まってみたら作業量は数倍になんてこともあります。また簡単にできると思われたことが、プラットフ
第7回 集合論――数学の「集合論」に，RDBの正体を見る
リレーショナル・データベース（RDB）のデータ構造やSQL命令による様々なデータ操作については，多くの人が知っていることだろう。しかしRDB技術の根底にある「集合論」を詳しく語れる人は少ないはずだ。集合論とRDBの結びつきを理解すれば，RDBの本質が見えてくる。 ITエンジニアの皆さんなら，米IBMサンノゼ研究所に在籍していたE.F.コッド博士（Edger.F.Codd，1923～2003）をご存知だろう。コッド博士は1970年，「A Relational Model of Data for Large Shared Banks（大規模共有データバンクのためのリレーショナル・モデル）」という有名な論文を発表した。現在の「リレーショナル・データベース（RDB）」（「関係データベース」とも呼ぶ）は，この論文が起源となって誕生したものだ。 コッド博士が数学の「集合論」を基に，表を使うRDBの仕組
ソフトウエア開発のどこまでを設計と呼ぶか？：ITpro
筆者には，現役でソフトウエア開発をしていたころから抱いている疑問がある。それは「ソフトウエア開発にとって，どこまでが設計なのか？」ということだ。その疑問は，エンジニアから記者に転職し，さまざまなSEやプログラマを取材するようになって，ますます深まるようになった。 一般にビジネス・アプリケーションのソフトウエア開発は，設計工程と製造（コーディング）工程に分かれる。ソフトウエア開発者は，設計者（主にSE）とプログラマとに分類され，設計者が書いた「仕様書（設計書）」にしたがってプログラマがコーディングする。仕様書にはさまざまな様式がある。オリジナルなものから，DFD(data flow diagram)，ERD（entity-relationship diagram），最近ではUML(unified modeling language)を使う場合もあるだろう。つまり設計とは「設計者が仕様書を書き
DB設計の神ツール「ERMaster」なら、ここまでできる
DB設計の神ツール「ERMaster」なら、ここまでできる：ユカイ、ツーカイ、カイハツ環境！（11）（1/3 ページ） 無料のEclipseプラグイン「ERMaster」とは データベースのテーブル設計を行うときに皆さんは、どのようにしているでしょうか？ いくつかの無料で利用できるツールが提供されているので、筆者はそれらを利用していましたが、最近「ERMaster」と呼ばれるEclipseプラグインの存在を知りました。 ERMasterは、ほかのツールに比べ、直感的で分かりやすいUI（ユーザーインターフェイス）に、カスタマイズ可能な、Excelで出力できるテーブル定義書、辞書機能など痒いところに手が届くERモデリングのツールです。本稿では、このERMasterについてご紹介します。 ERMasterの主な特徴、8つ ERMasterには、主に次のような特徴があります。 【1】直感的で使いや
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
モデリング・リファクタリングのススメ
ビジネス・モデリングなどのモデリングを始めてはみたものの，なかなか上手くモデリングできない…そんな悩みを持っている方も多いと思います。そこで，今回はモデリングを上達させるための「モデリング・リファクタリング」という方法をご紹介します。 モデリング・リファクタリングとは 「モデリング・リファクタリング」とは筆者が考えた造語です。（すでに誰かによって提唱されているかもしれませんが）筆者が発明したものではなく，モデリングに慣れている方なら自然とやっているようなテクニックです。 もともと「リファクタリング」というのは，小さなプログラム（例えばクラス）を作るときに，プログラムの外側の仕様（使われ方）は変えずに，中身の構造だけを変えることです。 なぜそんなことをするかというと，とりあえず仕様は満たしていたとしても，中身が汚い設計のままでは，変更に弱く，保守性も悪いからです。そこで，小さなプログラムを作
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dbdiagram.io - Database Relationship Diagrams Design Tool
サービス終了のお知らせ
Amazon.co.jp: データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして: 佐藤正美: 本
