Rustで真に安全なプログラムを書く方法 - かとじゅんの技術日誌
この記事はRust Advent Calendar 2021の12/8日の記事です。 Rust前提の記事として書きましたが、他の言語にも適用できる考え方なので、ほかの言語勢の方々もよければお付き合い下さい。 今回のテーマは「Rustで真に安全なプログラムを書く方法」についてです。 「真に安全なプログラム」の定義は以下とします。 挙動が安定し、結果が予測可能となる 正しさの基準に基づき、プログラムの間違いを検知することができる 「真に」とはドメイン知識に基づく正しさという意味です。詳しくは後述します。 それと「そもそもRustで実装されるプログラムは安全じゃないのか」という想定質問については「メモリの操作は安全。だが、それだけでは真に安全なプログラムにはならない」が答えになります。これについて興味がある方、ぜひ最後までお付き合いください。 「真に安全なプログラム」を実現するレシピとしては「関
ドメイン駆動設計に関する何か - 日々常々
2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ
サーバレス、これからどうなる？ DDD＆サーバレスの第一人者が語る、技術の未来
注目しているサーバレスサービス 佃松三郎氏（以下、佃）：次ですね。「今注目しているサーバレスのサービスがあれば教えてください」。 丹羽一智氏（以下、丹羽）：サーバレスのサービスというと定義が難しいですけど。「サーバレスで開発されたサービス」なのか「サーバレス開発で使えるサービス」なのかというところで定義が難しいですが、そもそも世の中にフルサーバレスで動いているアプリケーションはほとんどないのが現状なので、「開発で便利なもの」という意味だと、何回か推しているんですが、Datadogがすごくおすすめです。 普通のアプリケーション開発をしていてもそうだと思いますが、「ログの扱いをどうしよう？」ということがずっと課題になっていて、Fluentdで集めてS3に置くということを、みんながんばってやっています。 DatadogにはLogsというサービスがあって、特定のポートにあるサービス、IP・ポートに
Getter/Setterを避けて役に立つドメインオブジェクトを作る - かとじゅんの技術日誌
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから
責務と層の分離
設計の話 設計の話です。 責務 責務、誰がその仕事を行うかということを考えましょうというのはまぁさんざん言われていることだけど実際大事だと思う。 テクニックとしては委譲だのなんだのとあるけど、結局は「その仕事はその人に任せて本当にいいの？」にYesと答えられる場合にのみその作業をそのモジュールなり関数なりクラスなりに任せましょうという話ですね。 層の分離 プログラムが行う仕事は通常いくつかのオペレーションを組み合わせて実現されるわけだけど、それらの重要度というのは普通は一様ではない。 仕事によってはドメインレベルにしっかり固定されそれ以外のオペレーションがあり得ないものもあるし、今は一旦こうして実装しておくがあとで高確率で置き換える必要があるとかそういうやつ。 例えば今はハードコードしているが設定ファイルから読み込んだ値にしたい、DBを切り替えたい、データの中身が変更したいとかそういう感じ
「現場で役立つシステム設計の原則」はプログラミング設計の普遍的な教科書 - ビープラウド社長のブログ
日本のDDD（ドメイン駆動設計）界の父ともいえる増田亨さんが著した「現場で役立つシステム設計の原則」を頂いたので、早速拝読させていただきました。 本書をおすすめしたい人 本書は、システム開発で以下のような問題を抱えている人におすすめです。 既存システムのソースコードの可読性が低く、理解に時間がかかる 機能追加・改修時の影響範囲調査に時間がかかる 機能追加・改修時の工数が予想以上にかかる テストコードが書きにくいソースコードになりがち 機能を追加・改修時の影響範囲が大きくなりがちで、テスト工数がかさんでいる デグレの確認に気を使い、多くの時間をかけている 不具合が発生したときに、調査・解決に時間がかかってしまう 新しいメンバーがプロジェクトに参画した時に、業務知識を伝えるのに多くの手間がかかる これらの問題のために、生み出す価値以上に、仕事時間が増えている このような問題を解消し、変更に強い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リアクティブDDD