何か書きますスマートフォン用の表示で見る何か書きますたぶん。ミドルウェア/ソフトウェア/Webアプリケーションこの広告は、90日以上更新していないブログに表示しています。お絵かきツール【概要】システムやアルゴリズムの動作図(パラパラ漫画)を、DOT(Graphviz)風のテキスト記述から作図できるツールを作りました。github.com【用途】おもに木・グラフなどのデータ構造・アルゴリズムの動作の作図、OAuth/OpenIDやKerberos認証の動作の作図などに向いています。下記のようなDOT(Graphviz)言語風のテキスト記述から図を生成します。1枚絵ではなく、動作図(パラパラ漫画)を生成できます。より手書き風にしています)その他の特徴SVG画像ファイルをコマンドラインツールにより生成します。SVG属性を指定して、見た目を調整できます。各要素の配置が調整可能です。アニメーション(パラパラ漫画)の変化を記述するための差分記述モードがあります。下記のような図を作成できます。より手書き風にしています。既存のお絵かきツールには下記の使いにくさがありました。複数の図があるとき、1枚変更すると後続の図も修正しないといけないテキストベースの図表生成ツール要素の位置の指定がしにくい状態変化を表現しにくい要素の追加・削除で他要素の位置が変わってしまう変更点だけを記述できないので記述量が多くなりがち(図の枚数分、図全体を記述しないといけない)そこで図中の各要素を自動配置しつつ変化を表現するための動作図作成ツールを開発しました。設計ドメイン駆動設計は習得が難しいと思うのですが(少なくとも私には)、「エリック・エヴァンスのドメイン駆動設計」「実践ドメイン駆動設計」などの多くの本ではDDDが何か・どうあるべきかだけ書かれており、どのようにして習得していけばよいかがわかりにくいと思います。徐々にドメイン駆動設計のエッセンスを取り入れていくことができれば、早いスタートを切りつつより良い開発ができるようになると思います。ここでは、ドメイン駆動設計を習得しつつ現実の開発をどのようにすすめるのがよさそうか、私なりの考えを述べたいと思います。境界づけられたコンテキストに分割するまずはドメイン(問題空間)の分かれ目を整理して、実装のコンテキスト(解決空間)を分けるところから始めるのが良さそうです。コンテキストを分けることで、コード理解や変更の影響を境界づけられたコンテキスト内に閉じ込めることができます。コンテキストをざっくり分けることができていれば、ドメインモデル貧血症(=帳票クラス+トランザクションスクリプトによる帳票の操作)でもいい気がします。データモデリングにリポジトリの実装が引きづられてドメインモデル修正時に手間が発生するリスクはあります。コンテキストを統合していく必要があるのですが、コンテキストの統合でDDDっぽさを出すのはなかなか難しいように思います。DDDっぽくコンテキストを統合するのは後のフェーズでおこないます。コンテキストを区切ることができていれば、まずは「リポジトリの実体を共有(別のコンテキストの修正の影響が出てしまうのでDDD的にはNGとされる)」する実装でも良い気がします。「公開サービス+公表された言語」のローカルメソッド呼び出しなど。実装のコンテキストをわけていればリファクタリングしやすくなっているはずです。ドメインモデリング・レイヤー分け開発のペースが出てきたら、(おそらく帳票ベースの実装になっているのを)リファクタリングしながらドメインモデルを構築することでDDDっぽさをだすことができると思います。ドメインモデルが整理できたら、ドメイン層、アプリケーション層、インフラ層、ポート&アダプターなどに分離できクリーンアーキテクチャを実現できるようになると思います。コンテキスト間の統合ここまでのフェーズでは、コンテキスト間の統合に改善の余地がある状態でした。マナーでコンテキスト間を統合する必要がでてきます。〜もちこちゃんの大冒険〜【C91新刊】』には戦術的設計のエッセンスだけ取り入れるのではなく戦略的設計から導入するのが良いと書かれています。最低限の習得でスタートして、上記のようにフェーズ分けして徐々に習熟度をあげていけば、戦略的設計から開始できてよりよいドメイン駆動設計ができるようになると思います。それっぽいものはできる。それっぽいものはできる。改善の必要はあり「これでいいのか?」はつきまとうが、コンテキストの分割はなんとなくできるので難しさの本質ではなさそう。DDDのマナーにのっとりつつ、データの整合性をたもって永続化するにはどうすればいいのか?など詳細がわからず『実践ドメイン駆動設計』などを熟読する必要が出てくる。例:ドメインイベント+イベントソーシングとは?「リポジトリをわけろ」と言われているが、一貫性を保ちつつ統合するにはどうすればいいのかわからないので共有リポジトリを作ってつっこみたくなる。深い理解のために小さめのアプリケーション(Wikiのような)を作ってみました。記事の作成コンテキストと参照コンテキストを分離Markdown記事の作成でイベントが発行され、それにもとづき参照用HTMLページが生成インストール下記のようなコマンドをターミナルなどで実行します。下記コマンドで起動します。アクセスしてWiki風アプリケーションを利用できます。ユーザ認証・認可ユーザ認証・認可のモジュールはモック実装となっています。処理の流れ処理の流れは下記のようになっています。HTMLの記事を参照できるようになる構成パッケージ構成は下記です。userのコンテキストに分かれています。edit記事(Markdown)の編集まわりのコンテキストです。対する変更をイベントとして保持)。view記事(HTML)の参照まわりのコンテキストです。)をサブスクライブして参照用HTMLページを作成します。userユーザ認証、認可まわりのコンテキストです。カテゴリ配下の記事へアクセスできる」ことを意味する各ユーザがパーミッション(ポリシーの定義)にもとづいて実際にどのようにアクセス制御するか(ポリシーの施行)はそれぞれのコンテキストで実装します。パッケージ各種モック実装や、Flaskセッションに依存した実装をここに配置しています。メソッドが実行されます。DI(各種モックとの連携)をおこない、Flaskアプリケーションとして起動しています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。