に投稿 コメントを残す

全システムを統合するデザイン

集合による合成による自動開発システムはシステムの統合に強みがありますが、統合されたシステムのイメージ図がないと統合の何が良いのか伝わりにくいため、ちょっと全体を結合した際のGUIを載せてみました。

左側にあるのが各サブシステムとなります。それぞればらばらに売っていますが、統合すると各サブシステムのAPIを叩けるため、Vue.jsで開発するようなクライアントアプリで色々なことができるようになります。カレンダーや表やグラフなどに様々なサブシステムから引っ張ってきた情報を反映させることで一覧性を向上させることができます。

業務用システムは時間、人、リソースでシステム間を横断的に整理・分類したいことが多く、また、日々の業務単位では取り扱うデータ規模はそれほど大きくないというようなユースケースがみえてきます。下手にサーバ間の連携を密にするとシステムのリプレースが難しくなる負の側面がありますので、それぞれのシステムのAPIを独立に動作させながら業務に必要なデータをAPIでまとめてとってきて処理をするというのが多くの社内システムではよさそうです。社外に公開する決済システムのようなものですと不正対策で色々な制約をかける必要がありますが、社内システムの場合は多くの場合フレキシビリティの方が重要です。

そのような設計思想の下、各サブシステムで同じようなタイムスライスに対応したデータを取り出す仕組みをもっているのが本システムの特徴です。つまり、システム結合度をあげるのではなく、各サブシステムのAPI仕様を近くすることで汎用性を確保しています。

に投稿 コメントを残す

ガイドライン

生成されるコードのスタイルに関しては色々とカスタマイズをできるようにしていますが、いろいろとカスタマイズができることが必ずしも適切とは限らないので、デフォルトで標準的なガイドラインには近い設定にしています。

私のカスタム開発サービスでは laravel を使用していますので、特段の理由がなければ PSR-1 や PSR-2 などの標準的なガイドラインに準拠し、また、laravel で推奨されている命名ルールに従うという方針となります。

laravelのMigrations, Models, Controllers, Services, Views, Routes, Seeds, Factoriesなどの命名規則については若干の自由度があり、その点に関してはある程度カスタマイズできるようにする方針です。