『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』が出版されます - Magnolia Tech
ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法 作者:Vlad KhononovオライリージャパンAmazon 2021年にO'Reilly Media, Inc.から出版された「Learning Domain-Driven Design」の待望の日本語訳『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』がついに出版されます。 www.oreilly.com 訳者は、増田 亨さん！！ 2020年代に、ドメイン駆動設計を学ぶための最初の入り口としてどの本を読めば良いかは、かなり悩ましい...というのはよく言われるのですが（元祖のエバンス本はさすがにだいぶ古くなってきたし、回りくどい表現も多いし...）、そんな時におすすめできる1冊です。 2021年に原著が出版された時に買ってざっと読んでいたのですが、パート1で戦略的DDD（
DB設計書の管理が楽になるDBML入門 – DBMLの書き方,dbdiagram.io, dbdocs の紹介 – | SIOS Tech. Lab
こんにちは！サイオステクノロジーの安藤 浩です。DB設計書の生成が容易にできるDBMLをご紹介します。DBMLの入門として、DBMLの書き方、ER図生成方法、Github actionsでCIを実行して閲覧する方法をご紹介させていただきます。 DBMLとは DBML は DataBase Markup Language の略でDB構造を定義するために設計された言語です。 DB構造に焦点を当てており、可読性の高い言語です。 dbdiagram.io や dbdocs.io などを利用することでDBドキュメントの生成が可能です。 コードベースで図を生成できる点でPlantUMLと似ていますね。 DBMLの書き方 テーブルの書き方 まずはテーブルの定義の例をもとにDBMLの記法を紹介していきます。users というテーブルを作成してみます。コードは以下のようになります。 Table users
「共通基盤」を超えよ！ 今、Platform Engineeringに取り組むべき理由
OpenShift.Runで登壇した資料です。
シン・Kafka / shin-kafka
2024/04/10に行われたOCHaCafe Season 8-3「シン・Kafka」で使用したスライドです
ログラスを支える設計標準について / loglass-design-standards
設計カンファレンス extends OOCの発表資料です。
スタートアップでソフトウェアエンジニアとして10年たって大事にしていることリスト - tomoima525's blog
今から10年前の2014年4月に、いわゆるIT系大企業のDBエンジニアを辞めてメルカリでソフトウェアエンジニアとして働き始め、そこから紆余曲折を経て10年たった。 当時の予定通り、まだ現役でコードを書いている。海外に拠点は移り、色んな国の人たちと仕事をするようになり、役割もテックリード、マネジャー、CTOと変わってきた。ソフトウェア開発について考え方もさまざまな変遷を経ているが、少しずつ培ってきた、大事にしていることをあげてみる。 ソフトウェア/アーキテクチャ/コード ソフトウェアは他者の価値(i.e. 課題を解決する/コストをカットする)を生み出してなんぼ。コードが綺麗でも売上は立たない。 アーキテクチャやプログラミング言語のトレンドは変化する。追いかけるよりも、その時々のチームやプロダクトに合った設計やプログラムを選択する。 遊び心は大事。チームやプロダクトにそれほど合ってなくても新し
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
"Object-Oriented Conference 2024" の登壇資料です。 https://ooc.connpass.com/event/305241/
設計の知識と技能で駆動するソフトウェア開発
Object Oriented Conference 2024 登壇の機会をいただいたので、ここ数年、設計について考えていることを、言語化してみました。 はじめに 設計と開発プロセスの関係性 ソフトウェア設計の知識と技能 ① ソフトウェア設計の基礎知識 a. 基本課題 b. 解決のアプローチ c. モジュール化：基本となる４つの技法 ② モジュール化 a. モジュールの分類 b. オブジェクト指向プログラミングのモジュール化 c. ドメイン駆動設計のモジュール化 ③アプリケーションのモジュール構成（参照モデル） コア（中心） ポート（境界） アダプタ（周辺） ④モデル駆動設計 全体 事業活動、要件、アーキテクチャ コア（中央） 業務ロジック、ドメインモデル 業務機能、アプリケーションサービス アダプター（周辺） 記録モデル、データベーススキーマ 連係モデル、プロトコル設計 対話モデル、イン
The problem with using a UUID primary key in MySQL — PlanetScale
Universally Unique Identifiers, also known as UUIDs, are designed to allow developers to generate unique IDs in a way that guarantees uniqueness without knowledge of other systems. These are especially useful in a distributed architecture, where you have a number of systems and databases responsible for creating records. You might think that using UUIDs as a primary key in a database is a great id
Kafka Streamsで作る10万rpsを支えるイベント駆動マイクロサービス
CNDT2023 プレイベント 登壇資料
開発工程、リリースサイクルにおける課題とその対処法 ｜Autifyブログ
プロダクト・バックログから1〜4週間分の期間を抜き出したチームタスクリストのこと。予定通りにタスクが終わるかどうかを最優先で判断する。個々の分担に注視せず 「チームの仕事」 としてチームで成果を上げるのが特徴。「デイリースクラム」（朝のミーティング）を毎日必ず開き、昨日やったこと、今日やること、障害になっていることだけをチーム全体でシェア。細かい問題は個別に解決し、デイリースクラムは15分以内で終わらせることが目標。 ビジネス、開発の動きを支える上で、インフラに不可欠な「自動化」 ITシステムを開発する場合には多くの作業が発生します。開発後、新機能のリリースや更新ソフトウェアの適用、定期バックアップなどが必要で、これらは自動化されていないと手作業で行われます。 想像してみて下さい。もしもこの手作業が自動化されるとしたら…。 作業項目が大幅に減る 劇的なスピードアップ ヒューマンエラーの心配
組織が拡大しても質の高いDDDを守れるか？ログラス松岡氏・村本氏に聞くDDD浸透の切り札
組織が拡大しても質の高いDDDを守れるか？ログラス松岡氏・村本氏に聞くDDD浸透の切り札 2023年9月19日 株式会社ログラス EM 松岡 幸一郎 新卒で日本アイ・ビー・エムに入社し、大手銀行向け業務アプリケーション開発に携わる。4年後にビズリーチに転職。社外サービスや社内業務システムの企画・開発を担う一方で、「ドメイン駆動設計」についてブログなどで発信し、勉強会も数多く主宰。DDD普及活動を通じて知り合ったログラスに転職し、EMを務める 株式会社ログラス エンジニア 村本 雄太 新卒で人材系ベンチャーに入社し、インフラ責任者やテックリード、新規事業開発などの業務を担う。 2021年11月、ログラスに入社。スクラムチームのリーダーとして、チーム改善の推進や開発のリードを担う アジャイル開発の普及により、その関連手法であるドメイン駆動設計（Domain-Driven Design：以下、D
書籍「ソフトウェアテスト技法ドリル」ではテスト設計の考えとツールの使い方まで学べちゃいました | DevelopersIO
私は開発寄りのエンジニアであり、テストやQA専門の方と同じチームで頑張る機会が少なかったのですが、「なるほど、こうやって考えて、こういうツールを使っているのか」と非常に勉強になりました。 こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉（@bun76235104）です。 最近ではアジャイル開発やスクラム開発が多く採用され、ビジネスのスピードに負けないようにプロダクト開発・リリースのスピードが求められれている中で、「いかに効率よく、かつ効果的なテストをしていけるか」というのはテスト担当だけでなく、開発メンバー全員で考える必要があると思います。 とはいえ、実際のチームには「専任のQAエンジニアやテストアナリストはいない」ということは非常に多いと思います。 基本的なテスト技法は本で学んできたけど、どういう時にどんな技法でテストを設計すればよいの？ 本職のテスト
ソフトウェアに関わる人が知っておくといいかもしれない法則10個
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
Gmailで問題が生じる神奈川県立高校ネット出願システムの被疑箇所を調査、改善策を検討してみた | DevelopersIO
神奈川県高校入試のネット出願システムの不具合影響を受けた利用者として、Gmailを扱えないメール環境について外部から調査しました。 出願システムで独自実装されたメールシステムの不完全な実装と、メール関連のDNSの設定不備が原因であった可能性が高いと推測します。 2024年の神奈川県立高校入試出願システムの不具合の影響を受け、@gmail.comのメールアドレス を利用出来なかった一利用者として、 インターネットから参照可能な範囲で、出願システムのメール環境について調査。 被疑箇所の推定と、状況を改善する対策について検討する機会がありましたので、紹介させて頂きます。 神奈川県公立高等学校入学者選抜インターネット出願システムの稼動状況について MX設定 「mail.shutsugankanagawa.jp」のMXレコードを確認しました。 1/18(21時) $ dig mx mail.shut
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「ソフトウェア設計」のドメイン - 「データモデリングでドメインを駆動する」を読んで
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
プラットフォーム エンジニアリング ガイド
履歴データテーブルとの向き合い方_PHPerKaigi2024
