DDDで集約を跨いだ情報でロジックを構築するための「getter高階関数パターン」の紹介
はじめに 今回はDDDで集約を跨いだ情報でロジックを構築するためのパターンについて紹介していきます。 DDD（ドメイン駆動設計）における「集約（Aggregate）」とは、関連するオブジェクト（エンティティや値オブジェクト）を一つにまとめた単位のことを指します。集約はドメインのビジネスロジックの適用や整合性を維持するために定義されます。永続化は集約単位で行われます。 例えばECサイトの注文という集約には、一つの注文に複数の注文明細があるとします。この注文と注文明細はそれぞれがエンティティであり、このとき集約は「複数の注文明細を持つ一つの注文」という単位で管理され永続化されます。一つの集約の中に二種類のエンティティがあるということです。 Amazonで注文した時に、化粧水を2個、洗顔料を1個まとめて買ったときの注文を一つの集約として取り扱っているイメージです。 class Order( va
CodiumAIと共に行うテスト・リファクタリング
はじめに ここ一年でGitHub Copilotはかなり浸透し、Cursorなどの開発者向けのLLM（Large Language Models）ツールの利用も増えてきていることを実感します。 下記の通り、Copilotによって多くのコードが生成される時代となりました。 GitHub Copilotは改善され続けている。2022年6月にこのツールが初めて個人向けに提供されたとき、開発者のコードの27％以上が平均してGitHub Copilotによって生成されたものだった。現在では、この数字はすべてのプログラミング言語で46%に達し、Javaでは61%に跳ね上がっている。 https://github.blog/2023-05-09-how-companies-are-boosting-productivity-with-generative-ai/ CopilotやCursorも便利で愛用
LLM for 時系列分析の世界
以前、【LT大会#7】LLMの活用・機械学習・データ分析関係のいろいろな話題にふれようで、時系列基盤モデルについてLTをさせて頂きました。 他発表者のLTも面白く、私自身も時系列基盤モデルについて理解を深める良いきっかけとなりましたが、心残りはLLMを絡めた手法については時間を割けなかったことです。 そこで今回はLLM for 時系列分析に関するアイディアを簡単にまとめてみます。 おことわり 学習目的で調査・作成した内容がベースとなっており、誤りや他に面白い論文・事例がありましたら、教えて頂けますと幸いです。 主に以下Survey論文・Collectionリポジトリで取り上げられている内容の一部を対象としています。より網羅的に知りたい方は下記リソースを直接ご参照ください。 Large Language Models for Time Series: A Survey Position: W
LLMエージェントのデザインパターン、Agentic Design Patternsを理解する
「Agentic Design Patterns」と呼ばれるLLMベースのAIエージェント（以下、LLMエージェント）の4つのデザインパターンについて紹介します。 まず、「Agenticワークフロー」について説明し、続いて4つのデザインパターンを説明します Agentic Design Patterns Part 1 Agentic Design Patterns Part 2, Reflection Agentic Design Patterns Part 3, Tool Use Agentic Design Patterns Part 4, Planning Agentic Design Patterns Part 5, Multi-Agent Collaboration 動画もあります。 LLMエージェントについての説明は省略しているため、エージェントについて初見の方は以下記事をお勧
LLM APIを良い感じに呼べればOKな時に便利なlitellm
この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint"の25週目の記事です！ 1年間連続達成まで 残り28週 となりました！ こんにちは。ログラスのLLMチームでソフトウェアエンジニアをしているr-kagayaです。 LLMを使ったアプリケーション・機能を作りたいとなったらいくつかのライブラリ選択肢があります。代表例はLangChainでしょう。 最近はオブザーバリティツールとしてLangSmithが登場するなど、LLMシステムを構築する上で必要・便利なモジュールの網羅が進み、LLMアプリ開発のデファクトに向かって爆進しています。 プロダクションで使うことに批判的な声もありましたが、最近はver0.1(それでも0.1ですが)に到達。 LangChain、LangChain Community、LangChain Coreに切り出され、LangSmit
認可のベストプラクティスとDDDでの実装パターン
最近、少々複雑な権限機能の開発を担当している中で、対応方針を悩んでいたことがありました。 権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。 また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。 そこで、認可処理の設計のベストプラクティスやDDDの実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います！ 権限と認可 権限と切っては切れない関係にあるのが認可です。 権限はある操作を実行できる権利を指します。 それに対して、認可は操作を実行する許可を出すため仕組みのことを指します。 例えば、ブログ投稿サービスで考えてみると、以下のような感じです。 権限: 投稿者はポストを編集できる。 認可: ユ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
