SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902
MySQLで論理削除と正しく付き合う方法
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
データモデルはドメインモデルに先行する - 設計者の発言
関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD（ドメイン駆動設計）に関心を持つ技術者にとってお手本になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。 どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。 これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させ
CSSのユーティリティクラスと「関心の分離」——いかにしてユーティリティファーストにたどり着いたか（翻訳） - yuhei blog
Tailwind CSS作者のAdam Wathan氏による「CSS Utility Classes and "Separation of Concerns"」の日本語訳です。翻訳に当たって原著者の許諾を得ています。 2021年10月29日に全文再翻訳しました。 この数年の間で、私のCSSの書き方は、非常に「セマンティック」なアプローチから「ファクショナルCSS」と呼ばれるものに変わりました。 この書き方でCSSを書くと、多くの開発者からかなりの反感を買うことがあります。そのため、私がいかにしてここまでたどり着いたかを説明することで、その過程で得た教訓や洞察について共有したいと思います。 第1段階 「セマンティック」なCSS よいCSSのためのベストプラクティスとして、耳にするであろうことのひとつは「関心の分離」です。 考え方としては、HTMLにはコンテンツについての知識のみを含めるべきで
The table naming dilemma: singular vs. plural
The other day, while in a planning poker session, the question of the naming of a particular table arose. During that conversation, one of our developers suggested that the table shall have a singular name, while others questioned that idea and thought that every table names should be plural. This led me to ask this question: is there a better choice? Should table names be singular or plural? It’s
REST: ログアウトAPIのメソッドはPOST？ - Qiita
REST APIの設計について、ログアウトAPIのHTTPメソッドについて社内で議論があったので、メモしておきます。 ログアウトといっても連携サービス(OpenID Connectなど)からのログアウトなど、サーバサイドでのユーザ属性の変化など、データ変更を伴うものではなく、単なるセッション切り替えの話です。 結論: 方針 方針としては以下のように決めていくのがいいかと思います。 APIが存在しないべき: RESTfulならそもそもセッションのステートはサーバが持っていないはずなので、ログアウトAPI自体が存在しないべき. サーバサイドでDB変更などの処理を行っていないため、クライアントでtoken/sessionの破棄を行えば事足りるはず。 DELETE: TokenのrevokeならDELETEだろう. 名前やエンドポイントがlogoutとかでも意味的にはtoken revokeならD
Redux 再考 - mizchi's blog
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
まるで「ビックリ箱」、ウクライナで戦うロシア軍の戦車が抱える設計上の欠陥とは
（ＣＮＮ） 砲塔部分が吹き飛ばされたロシア軍の戦車の残骸は、同国のウクライナへの侵攻が計画通りに進んでいないことを示す最新の兆候だ。 ウクライナ侵攻の開始以降、これまで破壊されたロシア軍の戦車は数百台に上ると考えられている。ウォレス英国防相は２５日、その数を推計で最大５８０台と発表した。 しかしロシアにとっての問題は単に台数のみにとどまらない。専門家らは戦場を写した画像から、ロシア軍の戦車がある不具合を抱えていることが分かると指摘する。それは西側諸国の軍隊が数十年間にわたり認識している欠陥で、「ビックリ箱」効果と呼ばれている。ロシア側もこの問題については把握していたはずだと、専門家らはみている。 問題は戦車の弾薬の搭載方法に関連する。最新の西側の戦車と異なり、ロシア軍の戦車は回転式砲塔の内部に多数の弾薬を搭載している。被弾の際の危険は極めて大きく、直撃ではない場合でさえもそこから連鎖反応が
結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ？と思ったときの選択肢 - Qiita
自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf
最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita
TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一本槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる「イベントストーミング」がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で「結構日本でやられている取り組みとちがうなー」と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守（あるいは鹿鳴館精神）ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基本線となりつつある、、、のか？ まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも「ドメインイベント」として実装パタ
Python Design Patterns
Python Design Patterns¶ Welcome! I’m Brandon Rhodes (website, Twitter) and this is my evolving guide to design patterns in the Python programming language. This site is letting me collect my ideas about Python and Design Patterns all in one place. My hope is that these pages make the patterns more discoverable — easier to find in web searches, and easier to read — than when they were scattered acr
『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』 - snoozer05's blog
翻訳を担当した書籍『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン）が3月8日に発売されます。本書は、2020年1月に出版されたMark Richards, Neal Ford著『Fundamentals of Software Architecture』（O'Reilly Media）を全訳したものです。 www.oreilly.co.jp ソフトウェアアーキテクチャとは、ソフトウェアシステムの成功に欠かせない重要な土台です。そのためソフトウェア開発者には、効果的なアーキテクチャを実現するスキルが求められます。本書は、そうした効果的なアーキテクチャを設計、構築、維持するアーキテクトになるために必要なスキルや知識を、現代的な視点から整理して包括的に解説する書籍です。 ソフトウェアアーキテクチャの定義から、アーキテクトの役割、モジュールや
名前重要 | プログラマが知るべき97のこと
名前重要著者: Matz ネイテイブ・アメリカンの信仰に「すべての人物・事物には真の名前があり、その名前を知るものはそれを支配することができる」というものがあるのだそうです。ですから、彼らは自分の真の名前を秘密にして、家族など本当に信頼できる人にしか打ち明けないのだそうです。そして、対外的にはあだ名を用意してそちらを使うということです。そういえばアニメ化もされたU・K・ル=グウィンの「ゲド戦記」でも同じ設定が用いられていましたね。「ゲド」というのは主人公の真の名前なので物語中にほとんど登場せず、物語の中では彼は一貫して「ハイタカ」と呼ばれていました。 さて、プログラミングの世界において、この信仰はある程度真実ではないかと感じることがたびたびあります。つまり、事物の名前には、理屈では説明しきれない不思議なパワーがあるような気がするのです。 たとえば、私が開発しているRubyも、名前のパワーを
Patterns.PDF
Robert C. Martin Copyright (c) 2000 by Robert C. Martin. All Rights Reserved. www.objectmentor.com 1 Design Principles and Design Patterns Robert C. Martin www.objectmentor.com What is software architecture? The answer is multitiered. At the highest level, there are the architecture patterns that define the overall shape and structure of software applications1 . Down a level is the architecture th
開発者が知っておくべきSOLIDの原則 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています（頭字語はMichael Feathereによって名付けられま
【読書】Clean Architecture 達人に学ぶソフトウェアの構造と設計
読んだ本 Clean Architecture 達人に学ぶソフトウェアの構造と設計 Robert C.Martin著 を読みました。 書評（読書感想文）です。 設計とアーキテクチャーの目的 著者はまず設計とアーキテクチャー（著者は設計＝アーキテクチャーだと言っている）の目的から説き起こします。曰く `「ソフトウェアアーキテクチャーの目的は求められるシステムを構築・保守するために必要な人材を最小限に抑えることだ」 一瞬「んっ？」となって、しばらく後にそうかも知れないな、と思いました。これは趣味の話ではなく、ビジネスとしてソフトウェアを開発する場合の話をしているんですね。仕事なのに、結構趣味的に作っている人、保守なんて知らない〜、と思っているエンジニアにはピンと来ない話かもしれませんが、ビジネス視点から見ると確かに正しいですね。 ちなみに、自分はずっと楽しみながらソフトウェアを作って成長してき
単一責任原則で無責任な多目的クラスを爆殺する - Qiita
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cache 解体新書
脱ExcelしたいMarkdownテンプレート目次 - Qiita
「ほんとやめて！」トイレのベビーキープが鍵の近くにあった結果… 配置や設計などに様々な意見が集まる「笑い事じゃない」
