持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
ダイコン時代の設計手法 - ひがやすを技術ブログ
スタラジで、本来話したかったことをまとめておきます。 最初はユースケースからスタートします。 本当は、RFPをユースケースに落とすという工程が 前工程にあります。 ユースケースの粒度について神経質になると 失敗します。 画面系ならいくつかの関連のある画面をまとめたものが 1つのユースケース。 ものすごく狭い言い方をするとメニューから呼ばれる 関連のある画面群が1つのユースケース。 帳票系なら1つの帳票が1ユースケース。 バッチ系なら関連するジョブをまとめたジョブネットが 1つのユースケース。 ユースケースを状態とサービスに分離します。 サービスはステートレスです。 状態は永続的な状態とプレゼンテーション層における一時的な状態に わかれます。 永続的な状態はER分析され、エンティティ(JavaBeans)にマッピングされます。 ここでは、UI層における一時的な状態を サービスから切り離し、サ
[ 技術講座 ] Domain-Driven Designのエッセンス -目次-｜オブジェクトの広場
［技術講座］ DDD難民に捧げる Domain-Driven Designのエッセンス 第 1 回 ドメイン駆動設計とは 第 2 回 DDDの基礎と実践 第 3 回 大規模なプロジェクトへの適用 DDDパターンカタログ パターン名 参考訳 I. Putting the Domain Model to Work Ubiquitous Language ユビキタス言語 Model-Driven Design モデル駆動設計 Hands-On Modeler 実践的モデラー II. Building Blocks of a Model-Driven Design Layered Architecture 層状アーキテクチャ Smart UI （アンチパターン） 利口なUI Entities エンティティ Value Objects 値オブジェクト Services サービス Modules モジ
#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
Android cleanarchitecture
日本マイクロソフト株式会社 Digital Sales 事業本部 Digital Cloud Solution Architect 上坂 貴志 クロスプラットフォームに対応した .NET Core、.NET 5 を得てリリースされた .NET 6は待望の LTS (Long-term Support)です。新規開発であれば .NET 6 での開発を検討できますが、.NET Framework で作成された既存のシステムはどうすれば良いでしょうか。 .NET Framework は version 4.8 を最後に新機能の追加予定は今のところありません。今後のことを考えて .NET 6 へのアップグレードを検討したいところですね。 このセッションでは .NET Framework から .NET 6 へのアップグレードについての様々な情報をお伝えします。
これからの設計の話をしよう
Dagger2 generates code to handle dependency injection behind the scenes. It creates classes like DaggerBreadShop to manage component bindings and factories like BreadModule_ProvideBreadFactory to retrieve dependencies. When a dependency is requested, it uses the factories to resolve the dependency by delegating to the corresponding module method, such as BreadModule::provideBread, which creates th
[ Android ] - これからの「設計」の話をしよう | Recruit Tech Blog
はじめまして。 6/1より入社いたしましたAndroidエンジニアの釘宮です。よろしくお願いいたします。 今日はAndroidの設計について語ってみようと思います。 その前に 「良い設計とはなにか」という議論が「正義とはなにか」という議論のようにいつまでたっても結論がでないのは、環境やチームメンバのスキルセット、ステークホルダーによって目指すべきゴールが変わるためだと考えます。 つまるところ、設計に正解はありません。 そのため以下で話すことは、「これが設計の正解だ！！」というわけではなくて、「こういう設計の仕方するとうまくいくっぽい」くらいのノリです。 あと、特にMVCとかDDDとか人によって解釈のズレが起きやすいところなどは、冗長になるのを嫌って自分の解釈で言い切っています。ご了承ください。 設計の目的について ハードルが下がったところで、早速。 まず設計の目的ってなんでしょうか？ この
![[ Android ] - これからの「設計」の話をしよう | Recruit Tech Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/a2437e1635f82304e06624b7c640608b0941d92d/height=288;version=1;width=512/https%3A%2F%2Ftechblog.recruit.co.jp%2Fassets%2Frmp%2Fthumbnail%2F5222.jpg)
DB設計でこだわりたい三つの要素
http://connpass.com/event/10849/ しょぼちむにデータモデル設計について教えてくださいの会 #syoboben で話した資料です。Read less
ドメイン駆動設計のリファレンス本 | GuildWorks Blog
井上です。 現在、ドメイン駆動設計(Domain Driven Desing . 以下 DDD)を用いて開発を行っています。 DDDの参考書籍といえば、もちろん「エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう」(以下 DDD本)ですが、その著者であるエリック・エヴァンスが最近(2014/9/22)「Domain-Driven Design Reference: Definitions and Pattern Summaries」という新しい本(以下 DDDリファレンス本)を出していることに気がつきました。 DDDリファレンス本とは 早速DDDリファレンス本を取り寄せてみました。８８ページと非常にコンパクトな本になっています。 内容的には、以下で公開されているPDFに新しい図や写真を追加してペーパーバックとして出版したもののようです。 DDD REFERE
時間をかけて、つまらないものを作りたいか？ - futoase
時間をかける つまらない想像話を以下に書く。 失敗してはいけない。成功しなければ行けないプロダクトだ。 企画から色々と実装アイディア、目的とするユーザー像を聞いている。 それに見合ったシステムを実装しなければならない。 あと6ヶ月で。その間は徹底的に企画と話をする。 部長と話しをして、駄目だったら作りなおす。 6ヶ月の間、エクセル上にガントチャートを引き、開発スケジュールを引いた。 企画・営業は2名。そのうち1名はマネージャ的な担当を行う。 部長は最終決定を下す(と聞かされている)。 エンジニアは3名。チームとしてはまあ良いほうだろう。 3ヶ月後 何を作っているのかわからなくなってきた。 具体像もわからない。 エクセルに書いたガントチャートは、意味を成していない。 ガントチャートを直そうと思うと、他の予定もずらさなければいけなくなり、 だるくなってだれも更新しようとしない。 システム全体の
あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに この記事は数百万行の動的型付き言語のWebアプリケーションのリファクタリング、アプリケーションアーキテクチャの再設計の経験を基に、有効だと思われる考え方やアプローチを抜粋して紹介するものです。言うまでもなくあらゆるコードベース、アーキテクチャにおいて有効なものとは限りませんので、各々の環境や状況から適切に判断してください。
Amazon VPC環境にメンテナンス用の踏み台サーバを構築する | DevelopersIO
よく訓練されたアップル信者、都元です。前回は「Amazon VPCを使ったミニマム構成のサーバ環境を構築する」と題して、Amazon VPCに小さなサーバ環境を構築しました。この環境は、アプリケーションサーバ（Webサーバ）がユーザからのHTTPを受け付けつつ、管理者によるメンテナンスのためのSSHの受け付けも兼ねている状態です。セキュリティの観点からは、あまり好ましい状態とは言えませんね。 そこで今回は、メンテナンスのための踏み台(bastion)サーバを構築し、よりセキュアな構成にしてみましょう。環境の構成図は右の通りです。まず、アプリケーションサーバはHTTPのみを受け付けるようにSecurity Groupを調整します。また、public subnetの中にもう一つサーバを起動し、踏み台として使います。こちらはSSHのみを受け付けるように調整します。踏み台サーバは常時起動しておく必
【AWS】VPC環境の作成ノウハウをまとめた社内向け資料を公開してみる | DevelopersIO
よく訓練されたアップル信者、都元です。今回のお題は久しぶりにVPCです。 この記事は、アップデート版が存在します。最新情報は【AWS】VPC環境構築ノウハウ社内資料 2014年4月版を参照してください。 VPCを利用する理由 弊社で構築するAWSのサーバ環境は、一部の例外を除いて全てVPCを利用しています。 突然ですが、筆者はあまり大規模なシステムに携わった経験がありません。大規模なプロジェクトだと「数百数千台のサーバがラッキングされ、それが論理的なネットワークで区切られていて」「複数のデータセンターが冗長化された専用線で結ばれて」等、正直ちょっと想像つかない世界があるんだと思います。よくわかんないですが。 (c)John McStravick. (CC BY 2.0 Licensed) 逆に、小さなシステムであれば、月々数万円でレンタルサーバを借りて「1台のマシンの中にWebサーバとDB
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
