[B! システム開発] auzooのブックマーク

チームで機能設計するためのPlantUML標準化 | フューチャー技術ブログ

はじめに現在所属しているプロジェクトではWebAPIやバッチ処理の設計の一環としてPlantUMLを利用しています。効率よく品質高くアウトプットを出すためには、プログラミング言語に対してコーディング規約があるように、UMLに対してもチームで設計するにあたり一定のルールを決める必要があります。そこでプロジェクト内のPlantUMLを使用するうえでのガイドラインやルールをまとめる機会があり、せっかくなのでそれを記事化します。記事のゴールシーケンス図設計におけるPlantUMLの標準化必要最低限のルールだけに絞ってチーム設計の生産性と品質を上げる記事の前提ルールの想定の利用シーン：チームで大量生産する業務機能の処理フローを表現するために使う場合を想定。また、この記事に記載されているルールはRDBを中心的に使用したAPI処理やバッチ処理等を念頭に置き決められたものです。ルールの想

auzoo 2020/06/21

システム開発

リンク

ドメインモデルとは(「現場で役立つシステム設計の原則」より) - Qiita

業務で扱う(最小)単位でデータとロジックをひとまとめにして整理する技法ドメインモデルが実現する世界どこに何のロジックが書いてあるか、(ソースを見るだけで)わかる改修しやすいプログラムドメインモデルで解決したい問題どこに何のロジックが書いてあるかわからない問題 - わからないから適当に書く→適当に書くからわからない → わからないから・・・ - ある修正をしようと思っても、どこまでが影響範囲かわからない - 使用している箇所全grepして調査 - 同じような処理、分岐が重複してしまうこれを解決したい。これだけを考える。なぜ(今までのシステムは)改修は難しいのか機能クラスと、データクラスをわけてしまうからそのデータクラスを呼べる箇所 = 業務ロジックがかけてしまうどこになにが書いてあるかわからなくなる共通クラス、Utilクラスを作ってしまうから誰でも呼べる = そのクラ