2024年7月13日の大吉祥寺.pmで発表した「古典ドメインモデリング(パターン)の解脱」のスライドログです。 この2冊で書かれているドメインモデルパターンを「古典」の対象にします。 ドメインモデルパターンは「複雑さに対処するため」と述べています。が、古典では次の2点が課題となっていると考えます。 これら2点について個別に見ていきます。 まずドメインモデルパターンから。 Patterns of Enterprise Application Architecture(以降PofEAA)ではこのように定義されています。 PofEAAのドメインロジックの章で使われている「収益認識」の例を取り上げます。 ContractやProduct, RecognitionStrategyなどといったクラスが作られて、これらのインタラクションでビジネスロジックが実現されると説明されています。 では、これらのド
（続きは来週かな？） さて、前編を公開したのっていつでしたっけ……？ すみません、いろいろ立て込んでる間に2週間くらい経っていました。「関数型ドメインモデリング」、続きである第3部を読み終えたので、その感想を書きなぐっていきます。 ﾋｴｯ 感想 Amazonのページ 第３部 モデルの実装 第８章 関数の理解 この章では、関数と関数合成について説明。関数プログラミングとは、「関数が非常に重要であるかのようにプログラミングすること」。 関数型とオブジェクト指向でのアプローチの違い： オブジェクト指向 プログラムのパーツは、クラスやオブジェクト パラメータ化には、インタフェースや依存関係の注入を使用 再利用には、継承やデザインパターンを使う 関数型 プログラムのパーツは、関数 パラメータ化には、関数を使用 再利用には、再利用可能なコードを関数にまとめ、関数合成を使う 『8.2 「もの」としての関
『大吉祥寺.pm - connpass』に参加してきたのでそのメモです、 各発表の感想 ざっと見たものだけピックアップで… ※資料スライドは見つけたら貼ります。 大吉祥寺.pm 基調講演 基調講演の登壇資料ですhttps://t.co/LtliDCMwZm #kichijojipm— 大西康裕 (@yasuhiro_onishi) 2024年7月13日 感想 出てくるフレーズが一つ一つ面白いご自身の歴史の発表 前夜に行われた生存者バイアスナイトを地で言っている内容だった 人に歴史あり、というのを感じる発表だった 関連リンク 株式会社 エーツー はてなのポッドキャスト Backyard Hatena #32 - 15年前のはてなと組織・基盤開発本部のこれから（id:onishi） #byhatena - Hatena Developer Blog 多様性の時代を生き抜くキャリアプラニング 本
ようやく、自分の中で例外処理系について頭が整理されてきたので、メモしておく。 実際のシステムは自分一人でやっているわけではないし、色んな制約もあるので、この通りには行かない。あくまで一般論。ま、普通だと思うけど。 例外の区別 ①正常処理 ・通常の業務処理。業務継続 ②業務例外系正常処理 ・ビジネスルール違反などの業務例外発生時の処理。 ・業務継続。想定可能な例外処理。 ③業務例外系異常処理 ・滅多に起きないようなビジネスルール違反。想定不可能な場合 ・業務停止。運用担当者による違反状態の是正が必要。 ④システム例外 ・システムの異常、バグ。想定外 ・システム停止。運用担当者による是正が必要。 それぞれ、どう対応するかというと。 ①正常処理 ・普通に ・ログレベルはINFO ②業務例外系正常処理 ・原則、言語の例外処理機能を利用しない。 ・例外状態は２値管理でいいなら、boolean,３値以
知識のunlearningをちゃんとやる - Learning Go, 2nd Editionの読書感想文 - じゃあ、おうちで学べる
はじめに Go言語の入門書として広く知られている"Learning Go"の第二版が発刊されました。第一版を読んだ際、Go言語のシンプルさと美しく整然とした構文に感銘を受けたものの、常に進化を続けているため、過去の知識にとらわれることなく、新しい概念や手法を柔軟に取り入れていく姿勢が何よりも重要であると感じました。 learning.oreilly.com ソフトウェアエンジニアとして成長を続けるには、アンラーニング(unlearning)の精神、つまり過去の知識にとらわれることなく、絶え間なく新しい知識を吸収し続ける姿勢が欠かせません。どんな達人でも鍛錬を怠れば老いるのが自明ですから、知識の新陳代謝のための学び直しが必要不可欠なのです。 この第二版では、中身がかなり改訂されており、Go言語のベストプラクティスがより深く理解できるようになっています。特に、ジェネリクスのサポートについての記
DDDにおいて、システムからは更新しないようなマスタデータもentityとしてrepositoryから取得してくるのが望ましいですか？ また、マスタデータをDBではなくenumで管理している場合、そのenumをentityとして扱うべきですか？ システムにおいてマスタデータを変更する契機が無い場合は可変ではないのでentityではなくvalue objectでしょうか？ 一般論で答えますね。 システムから更新しないマスターデータをエンティティとしてリポジトリから取得すること そのマスターデータがビジネスロジックに関わる重要な概念を表現し、ドメインの一部として扱われるべき場合は、エンティティとして扱いリポジトリから取得するのが適切です。ただし、更新されないデータであれば、キャッシュの利用を検討するとよいでしょう 列挙型で管理しているマスターデータをエンティティとして扱うべきか 列挙型で管理さ
こんにちは、まさきち(@masakichi_eng)です。 大吉祥寺.pmというカンファレンスに参加してきました。 とても良い体験でしたので記録を残しておこうと思います。 kichijojipm.connpass.com 実は吉祥寺に降り立つのは初めて。 電車から降りて会場へ向かう時からワクワクしていました。 着きました！🐿️#kichijojipm pic.twitter.com/zfuNravmM3 — まさきち (@masakichi_eng) 2024年7月13日 受付でおみくじが引けるということで引いてみると、 めでたく大吉！(大吉祥寺だけに！？笑) 大吉！ pic.twitter.com/Fw9APfz9e0 — まさきち (@masakichi_eng) 2024年7月13日 セッション感想 聞いた中で特に私に刺さったセッションを一部感想と共にご紹介します。 基調講演 sp
はじめに そもそも話題の背景 低下の要因たち 仕様変更に至るまでの経緯 計測方法の見直し テストファイルがあるものだけ抽出する(ホワイトリスト型) 除外したい pkg を名指しする（ブラックリスト型） まとめ はじめに こんにちは、トモニテ開発部ソフトウェアエンジニア兼、CTO 室 Dev Enable グループの rymiyamoto です。 最近はエルデンリングが再燃しています。 2024/06/18 に Go Conference 2024 の非公式イベントとして の Go BASH が開催されました。 andpad.connpass.com その際に go の ver 1.22 におけるテストカバレッジについて話をしてきたため、その内容を記事にまとめたものです。 speakerdeck.com そもそも話題の背景 go1.22 が出たタイミンで影響少なそうなリポジトリで試しにアップ
DTO（Data Transfer Object）とは？ 「Data Transfer Object」（DTO）は、データの受け渡しや共有を行うためのオブジェクトを表すデザインパターンです。 主に異なるコンポーネントや層間でデータを転送するために使用されます。 ※データベースからのデータ取得や外部サービスとのやり取りなど、データを異なるコンテキストで受け渡す必要がある場面で特に役立ちます。 DTOクラスの書き方 DTOクラスは、特定のデータ構造を表すためのクラスを作成します。 DTOクラスは、プロパティ（データ）とそれにアクセスするための以下のメソッドが一般的と言われています。 ゲッター セッターメソッド DTOクラス使う理由 外部からプロパティにアクセスする際にカプセル化を保ちながらアクセスができます。 VSCodeなどのエディタでジャンプできなかったところでも、DTOクラスを自体を返し
【OSS情報アーカイブ】Open Lowcode | マジセミ
マジセミドライブ ウェビナー関連のニュースやITサービス＆ツールの最新情報を随時配信します。 TOP 記事一覧 【OSS情報アーカイブ】Open Lowcode OSS情報 2020.01.01 【OSS情報アーカイブ】Open Lowcode ※当記事に記載されている情報は、古くなっている場合があります。オフィシャルサイトで最新情報をご確認ください。 「Open Lowcode」とは 概要 Open Lowcode(オープンローコード)とはローコード開発環境です。特定のアプリケーションを迅速かつ正確に構築して、最小限の予算でそれらを拡張できます。「財務アプリ」「タスク管理アプリ」「複雑データ処理アプリ」「セキュリティ管理アプリ」「ワークフローアプリ」などを素早く開発できます。 基本説明 Open Lowcodeでは、空白のシートから始めて、アプリケーションテンプレートで必要なものを定義し
この記事は、「SOLIDの原則を心で理解する」に関するシリーズの締めくくりとして、その最後の原則であり、重要な「依存性逆転の原則（DIP: Dependency Inversion Principle）」について解説します。 これはおそらく5つの原則の中で最も重要なものであり、単一責任の原則（Single Responsibility Principle）やリスコフの置換原則（Liskov Substitution Principle）とともに、とても優れたアーキテクチャパターンである基礎を形成しています。 高レベルのモジュールと低レベルのモジュールについての説明は以下の通りです。 高レベルのモジュール これらのモジュールは通常、ビジネスロジックやアプリケーションのオーケストレーション（調整）を含みます。複雑なタスクの調整やビジネスルールの適用を担当することが多いです。 低レベルのモジュー
OOC 2024 参加レポート
こんにちは！Septeni Japan株式会社でデータエンジニアをしている大志万といいます。 Object-Oriented Conference 2024 に参加してきました！ このブログでは整理の意味も込めて、参加したセッションとその感想を記載したいと思います。 参加した背景 業務ではPythonを書く機会が多いのですが、これまでPythonは我流で勉強していました。 しかし、うまく書けていないと思うことが多かったため、オブジェクト指向だったり、DDDだったりを勉強している最中、ちょうど先輩エンジニアにOOCに行かないかと誘われ、参加してきました🫠 DDDに興味があったので、実際にDDDを導入してみた系のセッションを中心に見て回っていました！ 参加したセッションとその感想 チームでモデリングを育てる上で考えたこと・気づいたこと 感想 DDD初期導入時「モデル図やユースケース図が更新さ
07/12(金)に仕事で東京に出張→宿泊だったので07/13(土)の 大吉祥寺.pm に参加してきた。 参加登録する時点ですでに20人弱待ちの補欠だったけど、このくらいなら余裕で繰り上がるだろうと参加登録。前日の夜に繰り上がりで参加できるようになった。 ちなみにpmはPjM(プロジェクトマネージャー)やPdM(プロダクトマネージャー)の略ではなくPerl Monger(Perl使い・Perl屋)らしい。た、多分ね。 オープニングトーク中には会場に着く時間にホテルを出たけれど、四ツ谷での乗り換えを2度も間違え 、更に 特別快速に乗るミス も重なり、吉祥寺駅に到着したのはちょうど基調講演が終わったくらいの時間だった。 飲料情報にあった自販機で飲み物を買っていると今回の登壇者の すてぃお さんがいたので(勇気を出して)話しかけ、お話をしつつ会場まで行った。 受付をしようとしたら Kirika_K
こんにちは、「Drupalの開発・導入支援・保守管理サービス KAIZEN 」 をご提供するANNAIです。 このポストは Drupal プロジェクトの創始者およびリードであるドリース・バイテルトによる最新のブログポストの翻訳です。ここでドリースは、MACH や Jamstack のような比較的新しいアーキテクチャが、Drupal のような従来型の CMS と同じような形態に「進化」しているという見解を幾つかの例と共に示しています。 また Drupal のモジュラーなアーキテクチャーにも触れ、同 CMS がモノリシックであるという批判が的を射ていないことについても説明し、これらのアーキテクチャーの特性や長所・短所についての冷静な分析を添えた上で、テクノロジーを評価する際にはアーキテクチャーに惑わされず、何を基準にすべきかについて語っています。 Jamstack、MACH、また Drupal
大吉祥寺.pmに参加しました！ 大吉祥寺.pmに参加しました！ 私はPerlを書いたことがなく、Perl Mongerではなかったのですが、タイムテーブルにとても興味がある話題がいくつもあったので参加してみることにしました！ 飲食店経営の話から、ドメインモデリングの話まで、本当に幅広いテーマを聞くことができてとてもよかったです。 各セッションについて 基調講演：「生存者バイアスナイト」後夜祭 X スライド ご自身の黒歴史の紹介という形で、大西さんのこれまでの歩みについてのお話。Perfumeのファンサイトを運営し、公式にも認知されていた話や、アルバイトしていた中古ゲームショップをオーナーから買い取って業績を改善した話。はてなを立ち上げた時の話など、目から鱗のお話をたくさん聞くことができた。 私も今キャリアの転換点にある中で、新しい環境を楽しみながら、先には素晴らしい世界が広がっていると信じ
Amazon Bedrock のエージェントがメモリ保持とコード解釈をサポートするようになりました (プレビュー中) | Amazon Web Services
Amazon Web Services ブログ Amazon Bedrock のエージェントがメモリ保持とコード解釈をサポートするようになりました (プレビュー中) Agents for Amazon Bedrock を使用すると、生成人工知能 (AI) アプリケーションはさまざまなシステムやデータソースにわたって多段階のタスクを実行できます。数か月前、エージェントの作成と設定を簡素化しました。7月10日、フルマネージド型の 2 つの新機能をプレビューで紹介します。 複数のインタラクションにわたってメモリを保持 – エージェントは各ユーザーとの会話の概要を保持できるようになり、特にユーザーとのやり取りや、フライトの予約や保険金請求の処理などのエンタープライズオートメーションソリューションといった複雑なマルチステップタスクで、スムーズで適応性の高いエクスペリエンスを提供できるようになりました
独自のテンプレートを共有する - Microsoft Power Platform - Power Platform
コンポーネント ライブラリ コンポーネントはキャンバス アプリの再利用可能なビルディング ブロックであるため、アプリ メーカーは コンポーネント ライブラリ を使用してアプリ内でまたはアプリ間で使用するカスタム コントロールを作成できます。 コンポーネントは、カスタム プロパティなどの高度な機能を使用して、複雑な機能を有効にすることができます。 コンポーネント ライブラリ は、容易にするコンポーネント定義のコンテナです: コンポーネントを検出および検索します。 更新を公開します。 使用可能なコンポーネントの更新をアプリ メーカーに通知します。 コンポーネント ライブラリを作成し、作成者と共有して、アプリ間の一貫性を確保し、作成者が共通のコンポーネントではなくアプリのビジネス ロジックに集中できるようにします。 含めるのに最適な初期コンポーネントは次のとおりです。 ヘッダー ナビゲーショ
弊社ではMVP (Minimum Viable Product) によるFlutterアプリの開発をしております。 MVPは極力リリースまでの期間を短くし、その後も頻繁に仕様変更をする必要があります。 しかし、一般的な開発手法であるRiverpodでのMVVMだと「ModelとViewの混在化」が起こりがちで、リファクタリングに苦労することが良くありました。 そこで、Viewの複雑化を防ぐためのデザインパターンであるBLoCを用いつつ、Riverpodの利便性をなるべく損なわない手法を考案し、少しずつ改良を重ねてまいりました。 BLoCパターンとは MVCやMVVMなどの設計手法は「ViewとModelを分離する」ことを主目的としています。 これは、通常であれば問題ありませんが、Flutterはマルチプラットフォーム開発の出来るフレームワークということもあり、Viewが複雑化しやすい傾向に
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
古典ドメインモデリングパターンの解脱 - 大吉祥寺.pm - kawasima
「関数型ドメインモデリング」の日本語訳が出たので読んでみた(後編)
『大吉祥寺.pm』に行ってきたよメモ - コード日進月歩
Javaの例外処理についての備忘録 - まっつんの日記
DDDにおいて、システムからは更新しないようなマスタデータもentityとしてrepositoryから取得してくるのが望ましいですか？ また、マスタデータをDBではなくenumで管理している場合、そのenumをentityとして扱うべきですか？ システムにおいてマスタデータを変更する契機が無い場合は可変ではないのでentityではなくvalue objectでしょうか？ | mond
大吉祥寺.pm参加レポ - masakichi_eng’s blog
go1.22 からのテストカバレッジとの付き合い方 - every Tech Blog
【Laravel】DTO(Data Transfer Object)クラスを使った例の紹介 | kamiblog
SOLIDの原則を心で理解する - 依存性逆転の原則
大吉祥寺.pmに参加してきた #kichijojipm - カスタネット三原則
新しい古典：Jamstack と MACH が従来の CMS の概念に向け進化する | ANNAIマガジン
大吉祥寺.pmに初めて参加しました！ - Ohkuraのブログ
【Flutter】Riverpodが扱えるミニマムなBLoCパターンの構築