Rust で DDD を実践しながら API サーバーを実装・構築した（つもり） - Qiita
Rust 勉強中の身ですので、何かしら作ってみようと思い立ち、 API サーバーを構築してみました。 自力で一から公開できるサーバーを構築したのは初めてでしたので、試行錯誤の過程を記事にします。 作ったもの 何の変哲もない API サーバーです。 成果物は こちら にアップしました。 API サーバー Rust で実装 Web フレームワーク（Actor）: actix-web ORM: Diesel Docker イメージにして Heroku で稼働させる DB サーバー PostgreSQL を利用する Heroku PostgreSQL で稼働させる 開発方針 上記のインフラ構成を目標として、以下の開発方針を軸として調査や検証を行いました。 ローカルでの開発とサーバーへのデプロイはスムーズにできるようにする。 ローカルでテストや動作確認がスムーズにできるようにする：Docker の利
DDDを意識しながらレイヤードアーキテクチャとGoでAPIサーバーを構築する - Qiita
今の現場で初めてDDDに触れたので、よく採用されるアーキテクチャとしてレイヤードアーキテクチャを自分で0から実装してみました。 言語もよくセットで採用されているGoを採用してみました。 この記事の目的 0から実装して体系的にDDDとレイヤードアーキテクチャを学ぶ DDDに触れたことがない方にもわかりやすく説明する そもそもDDD(ドメイン駆動設計)とは 要約(引用)すると「ドメインの知識に焦点を当てた設計手法」です。 たとえば電子カルテのシステムを例に取ってみます。 電子カルテには患者情報や手術の予定、入院ベッドの空き具合などの概念があると考えられます。 医療関係者ではないソフトウェアエンジニアは実際につかうユーザー（医療関係者）が直面している問題やドメイン(領域)の概念、事象を理解することが必要です。 それらを理解し、ソフトウェアに落とし込む。落とし込み続けることを実践する開発手法です
これならできる！ドメイン駆動設計に役立つイベントストーミング - Qiita
はじめに コンテナ技術の進展に伴って、ビジネス環境の変化に迅速に対応できるマイクロサービスに関心が集まっています。最近では、マイクロサービスを分割する方法の一つとしてドメイン駆動設計が注目されています。ドメイン駆動設計では、業務に精通した方々や技術者が、モデリングなどいろいろな技法や専門用語を使い、それらを理解した上で設計を進めていきます。様々なステークホルダーとチームを組んで一緒に取り組むにしても、直観的にはとてもわかりづらいと感じています。そこで、いろいろと記事を調べてみたり、身近な技術者と意見交換をしたところ、イベントストーミングという手法がありました。イベントストーミングに関する記事は他の記事に比べあまり多くはないので、この場で共有しておきたいと思い掲載することにしました。これからドメイン駆動設計をはじめるという方や、既に取り組んでいるけれど進め方に悩んでいる方など、参考になれば幸
わかった気になるDDD入門記事まとめ - Qiita
はじめに こんにちは。はじめまして。tarokamikazeです。 これは、社内勉強会用に参考資料をまとめたものです。 この資料のゴール DDD専門用語について、どんなワードでググったらいいかわかるようになる DDDを知らない人が、戦術的DDD(軽量DDD)だけでもやってみようかなという気になる 前段; MVCの限界 余談ですが、凝集度・結合度の観点からするとRailsのMVCがどう問題があるかをコラムで紹介しています。MVCそれぞれの責務を図示すると、低凝集・高結合になっていることがわかります。 とにかく、凝集度、凝集度なのです。 pic.twitter.com/fDWv1ERJA1 — 松岡@技術書典8Day2え28 / DDDブログ書いてます (@little_hand_s) February 2, 2020 あえて過激に言うと。 ある程度の複雑度を持ったアプリケーションにおいて、M
軽量DDDは有りか？ - Qiita
その他のキーワードとして クリーンアーキテクチャ オニオンアーキテクチャ オブジェクト指向 トランザクションスクリプト 実際、軽量DDDは有りだと思うかどうか？ 有りだと思っている。値とロジックを一緒にしておくことでオブジェクト指向的になり、コードは整理される。 DDDとオブジェクト指向の違いは？ DDDもオブジェクト指向の一種ではないか。DDDはその中でもドメイン部分に注力する。 そのせいかファイルの入出力などはトランザクションスクリプト的な書き方になりがち...。 クリーンアーキテクチャやオニオンアーキテクチャを適用しないとDDDにならないか？ アーキテクチャとDDDは切り離して考えられる。 違うアーキテクチャを採用してもDDDをすることは可能。 軽量DDDから重量（？）DDDに移行できるのか？そもそも境界線は？ コアドメインやサブドメインを意識してクラスを考え始めたらちゃんとしたDD
設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita
/// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>
#チケット料金モデリング でDDD+Clean Architectureする - Qiita
漢なら黙ってコードホトトギス TL; DR. 世は戦乱。 #チケット料金モデリング というハッシュタグにてアプリケーション設計を営みとする猛者たちに火蓋が切り落とされました。ワイも参戦すべく張り切っていったのですが、女子高生の無駄遣いを見たり女子高生の無駄遣いを見たり、女子高生の無駄遣いを見たり、iPad Proを買いに行っていたら2週間くらい経っていました。 さすがにこれでちょっとしたコードを晒すだけなのはアレなので、どうせならドメインモデリングだけにとどまらず、簡単なcliっぽい形にしてクリーンアーキテクチャを実現してみることにしました。言うならば 実践クリーンアーキテクチャチケット料金モデリングといったところでしょうか(ただ単に大きな話題に乗っかっただけともいう)。お題を提供してもらったかとじゅんさんに多謝です。 github repository サンプルコードだけ先に見せろよ、ま
ドメインロジックはドメインオブジェクトに凝集させる - Qiita
こんにちは。 最近、こんなツイートしたのですが、ドメインオブジェクトではなくアプリケーションサービス1などにドメインロジックが書かれてしまうことがあります。 アプリケーションサービスはドメインロジックを配置する場所ではない、それはドメインオブジェクトの役割。アプリケーションサービスは進行役。ここを間違うから簡単にドメインモデル貧血症になってしまうんだと思います。 — かとじゅん (@j5ik2o) August 18, 2019 最近、以下の書籍(以下 増田本)をマジメに読み直しました(笑)。ドメインモデル貧血症2を回避して、ドメインロジックをドメインオブジェクトに凝集させる方法に関して、増田本にいろいろ書いてあったので、そのエッセンスと僕の考察を交えて解説したいと思います3。 詳しい内容は以下の増田本を読んでください！ コード例はScalaですが難しい表現がないので、Scalaが分からな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
