ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP
Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に代数的データ型などの関数型のパラダイムを加えたよりタイプセーフな関数型DDDを紹介します。 本セッションではドメインモデリングによって発見したモデルやビジネスロジックをソフトウェアに反映する際により型を重視した設計を加えます。 型で表現する範囲が広がることでビジネスロジックをより明確にコードで表現できるようになります。 さらには型で表現されているためコンパイルフェーズで気付けるミスが増え、ソフトウェアの品質向上にもつながります。 関数型の考えをいれるといってもただ単にHaskellなどに代表される関
DDD入門：用語解説・モデリング編
はじめに こんにちは、クラウドエース Backend Division 所属の秋庭です。 私は今年新卒で入社したのですが、入った案件では DDD (ドメイン駆動設計)を元に設計・実装が行われていたため DDD について学ぶ必要がありました。 この記事は、私が何も知らない状態から DDD について学び始めた一歩目のアウトプットであり、同様にこれから一歩を踏み出す方の手助けになるものとなったら嬉しいです。 この DDD 入門記事は大きく「用語解説・モデリング編」と「コーディング編」に分かれており、用語の紹介と実際の作業を通して DDD の概観を紹介できればと思います。 この記事は「用語解説・モデリング編」となります。この記事の続きとなる「コーディング編」もぜひご覧ください！ 対象 想定読者 DDD の用語や概念、モデリングについてこれから学ぼうと考えている方。 記事内容 この記事では主に DD
【DDD入門】TypeScript × ドメイン駆動設計ハンズオン
TypeScriptとドメイン駆動設計（DDD）を組み合わせ、APIを構築するハンズオンガイドです。この本では、DDDとは何かという基礎的なところからソフトウェア開発における戦略的設計、戦術的設計まで、包括的な知識を提供します。 戦略的設計では、ビジネスの要求に合わせたドメインモデルの設計をイベントストーミングを用いて行います。その後、戦術的設計では、具体的なコードの実装に関連するDDDの原則と実践を学びます。 TypeScriptを使ってコードを書きながら、DDDの概念を実際のプロジェクトに適用するヒントを紹介します。
『UNIXという考え方―その設計思想と哲学』を読んだ - 30歳からのプログラミング
UNIX やそのツールはどのような考えに基づいて作られているのか解説した本。 UNIX が開発されていくなかで培われていった文化や考え方について書かれている。 www.ohmsha.co.jp UNIX が具体的にどのように動いているのかではなく、 UNIX はなぜそのように動いているのか、ということが主題。 そのため、 UNIX に限らずソフトウェア開発全般に適用できるような内容になっている。ソフトウェアだけでなく「ものを作る」こと全般に応用できる内容も多いかもしれない。 私も、現時点では UNIX そのものに対する熱意や探究心はあまりないので、 UNIX について知るためではなく開発の参考になる考え方がないかと思って読んだ。 9 つの定理が紹介されているのだが、まず思ったのは、「言うは易く行うは難し」という感じの定理ばかりだなということ。 例えばシンプルに保て、小ささを維持しろ、という
ヒットアプリ「ダブル計算機」って？開発者は定年後の63歳男性 | 毎日新聞
一つの画面に二つの電卓が並ぶいっぷう変わったアプリが、米アップルのスマートフォン「iPhone（アイフォーン）」と、タブレット端末「iPad（アイパッド）」で公開され、人気を呼んでいる。その名は「ダブル計算機」。開発したのは、兵庫県の63歳の男性だ。リリース後しばらくはダウンロード数が伸び悩んだが、ある改良を加えたことで数が大幅に増えた。その一工夫とは――。【後藤豪】 まず、機能を確認しておこう。画面中央に表示される「→」や「←」の矢印キーをタップすると、計算結果をもう一方の電卓に移すことができる。たとえば、片方の電卓で「89×15＝1335」を計算し、矢印キーをタップすることで計算結果の「1335」がもう一方の計算機に表示される（写真1）。そこから計算を続けられる。入力した計算式が表示されたままなので、ミスに気づきやすい。 また、それぞれの計算機で別々の計算をすることも可能だ（写真2）。
なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
変数(variable)と値(value) - ソフトウェア設計を考える
はじめてScalaに触れたとき、変数宣言(var)と値宣言（val)を使い分ける言語仕様に、なるほどなあ、と思った。簡単に言えば、変数(var)は再代入できて、値（val)は再代入できない。 プログラミングのスタイルとして、var宣言は命令的なプログラミング、val宣言は宣言的なプログラミングになる。どちらのプログラミングスタイルで書いているかを、varとvalで明示できるわけだ。 Javaだと言語の基本の仕組みはすべてが変数。final宣言をすることで再代入をコンパイルエラーにすることはできる。Javaは、C言語やC++などの命令的なプログラミングの系譜の言語なのですべて変数(variable)というのは、とうぜんの言語仕様だった。 命令的なスタイルから宣言的なスタイルに 命令的なプログラミングでは変数(variable)を使う。宣言的なプログラミングでは値(value)を使う。 再代入
Appleを追い出されNeXTを立ち上げたスティーブ・ジョブズを間近に見ていたエンジニアたちの証言
1985年にAppleを追放されたスティーブ・ジョブズ氏が創業した「NeXT」は教育用・ビジネス用のワークステーションのメーカーで、1996年にAppleに買収され、ジョブズ氏がAppleに返り咲くきっかけとなりました。NeXTが開発したオブジェクト指向型OS「NeXTSTEP」はその後のmacOSやiOSの基盤となっています。さまざまな質問に対して専門家が回答する質疑応答サイト「Quora」に投稿された「NeXTのエンジニアはどんな感じで働いていたのでしょうか？ジョブズ氏は普段から従業員と交流していたのでしょうか？」という質問に対して、当時を知るエンジニアたちが回答しています。 What was it like to be a software engineer at NeXT? Did workers interact with Steve Jobs? - Quora https://
達人プログラマー（第2版） 熟達に向けたあなたの旅 | Ohmsha
序文 目次 まえがき－第2版に向けて 第1版のまえがきより 第1章 達人の哲学 1 あなたの人生 2 猫がソースコードを食べちゃった 3 ソフトウェアのエントロピー 4 石のスープとゆでガエル 5 十分によいソフトウェア 6 あなたの知識ポートフォリオ 7 伝達しよう！ 第2章 達人のアプローチ 8 よい設計の本質 9 DRY 原則? 二重化の過ち 10 直交性 11 可逆性 12 曳光弾 13 プロトタイプとポストイット 14 専用の言語 15 見積もり 第3章 基本的なツール 16 プレインテキストの威力 17 貝殻（シェル）遊び 18 パワーエディット 19 バージョン管理 20 デバッグ 21 テキスト操作言語 22 エンジニアリング日誌 第4章 妄想の達人 23 契約による設計（DbC） 24 死んだプログラムは嘘をつかない 25 表明を用いたプログラミング 26 リソースのバラ
個人的なアプリケーション設計のバイブル3選 - Runner in the High
自分が本格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば本当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション
On Loving C.. 日本語訳
以下の文章は、Michael Feathers による On Loving C.. の日本語訳である。 文中の固有名詞などについて理解の助けとなるよう Wikipedia へのリンクを加えさせてもらった。 認めなければならないことがある。私は C を愛している。しばらくはそれを意識していても、忘れがちだ。Ruby、Haskell、OCaml、C++、Java、そして C# に心移りしたこともある――今も多くの言語に時間を割いているが、C の元に戻ってくると、私は故郷に帰ったような気持ちになる。 私は何十年も前に Kernighan と Ritchie の本をパラパラとめくったときのことを覚えている。C にはとても欲求不満を感じた記憶もあるが、とても満足を与えてくれたことも覚えている。C にはヘンなところがあるが、振り返ってみると、それは多くの他の言語のヘンさに比べれば不可解なところはずっと
ドメイン駆動設計のエンティティとクリーンアーキテクチャのエンティティ
概要 ドメイン駆動設計の有名な用語にエンティティというものがあります。 ほとんどドメイン駆動設計の代名詞のひとつと言っても過言でないほどの有名さを誇るこちらの用語ですが、なんとクリーンアーキテクチャにもまったく同じエンティティという用語が出てきます。 このエンティティという用語は名前こそ同じではありますが、実は完全に同じものを指しているわけではありません。 とはいえまったく違うものである、というわけでもありません。 要するにややこしい。 この記事はこのややこしい用語について、ドメイン駆動設計とクリーンアーキテクチャのそれぞれのエンティティが何を指していて、それがどのように異なっているのかについてを解説します。 それぞれのエンティティ そもそもエンティティとは何でしょうか。 英和辞典を引くとエンティティとは「存在［実在］物」といった意味が出てきます。 これはかなり抽象的な意味です。 つまり、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8