ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
11 likes4,330 views
DevLove 2010/10/27 発表資料。
More Related Content
What's hot (20)
Similar to ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation (20)
More from Tadayoshi Sato (11)
Recently uploaded (11)
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
- 1. ビジネスロジック 実装進化論 2010年10月27日 佐藤 匡剛 http://ameblo.jp/ouobpo An Evolution of Business Logic Implementation
- 2. ? 仕事 - Software AG株式会社 グローバルコンサルタンシー サービス webMethodsコンサルタント - 書籍の執筆／翻訳など ? Web - ブログ: http://ameblo.jp/ouobpo - Twitter: tadayosi ? 趣味 - Kindleで読書 - 日本ベジタリアン協会会員 佐藤 匡剛（さとう ただよし） http://www.?ickr.com/photos/robertnyman/189691155/
- 8. #!/usr/bin/env perl use strict; use CGI::Carp qw(fatalsToBrowser); require ‘util.pl’ my %FORM = util::read_form('POST', 'utf8'); # ビジネスロジック？ ... print "Content-type: text/htmlnn"; print<<HTML_END; <html> <head> <title>注文確認</title> </head> <body> ... </body> </html> HTML_END
- 10. public class OrderServlet extends HttpServlet { protected void service( HttpServletRequest request, HttpServletResponse response) { processOrder(request, response); request .getRequestDispatcher( “/order/confirm.jsp”) .forward(request, response); } private void processOrder( HttpServletRequest request, HttpServletResponse response) { // ビジネスロジック？ ... } ...
- 14. public class ProcessOrderServiceImpl implements IProcessOrderService { private IOrderDao fOrderDao; private ICustomerDao fCustomerDao; public List<OrderBean> findOrders( CustomerBean customer) { ... } public void confirmOrder( OrderBean order, CustomerBean customer) { ... } public void cancelOrder( OrderBean order, CustomerBean customer) { ... } ...
- 15. Transaction Script ? プレゼン、ビジネスロジック、データアクセ スの各層は分離される ? ビジネスロジックはユースケース単位で構成さ れる × ビジネスロジックが複雑になると、コード重 複の制御が難しくなる
- 17. public class ProcessOrderServiceImpl implements IProcessOrderService { private IOrderLogic fOrderLogic; private ICustomerLogic fCustomerLogic; public List<OrderBean> findOrders( CustomerBean customer) { return fOrderLogic.findByCustomer(customer); } public void confirmOrder( OrderBean order, CustomerBean customer) { fOrderLogic.confirm(order, customer); } public void cancelOrder( OrderBean order, CustomerBean customer) { fOrderLogic.cancel(order, customer); } ...
- 18. public class OrderLogicImpl implements IOrderLogic { private IOrderDao fOrderDao; private ICustomerLogic fCustomerLogic; public List<OrderBean> findByCustomer( CustomerBean customer) { return fOrderDao. findByCustomerId(customer.getId()); } public void confirm( OrderBean order, CustomerBean customer) { ... } public void cancel( OrderBean order, CustomerBean customer) { ... } ...
- 19. Table Module ? プレゼン、ビジネスロジック、データアクセ スの各層は分離される ? ビジネスロジックはさらに2層に分かれる - Service Layer ＝ ユースケース単位 - ドメインロジック ＝ DBテーブル単位 ? 実用レベルでは問題ないが、コードにムダが 多く美しくない
- 21. 総称関数（CLOS） ;;; クラス定義 (defclass order () ((number :accessor order-number ...))) (defmethod confirm ((self order)) (... (order-number self))) ;;; 実行コード (setq o (make-instance ‘order :number 12345)) (confirm o)
- 23. 総称関数 → オブジェクト class OrderLogic { static void confirm( OrderBean order, CustomerBean customer) { order.getOrderNo(); ... OrderLogic .confirm(order, customer); class Order { String orderNo; void confirm( Customer customer) { this.orderNo; ... order.confirm(customer); Table Module Domain Model
- 25. public class ProcessOrderServiceImpl implements IProcessOrderService { private IOrderRepository fOrderRepository; private ICustomerRepository fCustomerRepository; public List<Order> findOrders( Customer customer) { return fOrderRepository.findBy(customer); } public void confirmOrder(Order order) { order.confirm(); } public void cancelOrder(Order order) { order.cancel(); } ...
- 26. public class Order { private Customer fCustomer; public void confirm() { ... } public void process() { ... } public void cancel() { ... } ...
- 27. Domain Modelのメリット ? 再利用性、メンテナンス性が高くなる ? ロジックの置き場に悩まない ? 複雑なビジネスロジックをモデルによって 可視化できる ? コードの字面がシンプルになり、美しい
- 28. まとめ ?コードの重複排除を追究すると、自然 とTable Moduleまで り着く ?Table Moduleが総称関数によるOOの実 装と気づけば、Domain Modelへの道が 拓ける
- 29. 最后に
- 30. “Architecture teams must not siphon off all the best and brightest.” アーキテクチャチームに 最も優秀なメンバ を集めてはいけない。 — Eric Evans, Domain-Driven Design
- 31. テクノロジからドメインへ ? テクノロジの活用に忙殺されてい ないだろうか？ - 顧客に価値をもたらすのはイン フラやフレームワークではない ? ビジネスに真の力を与えるのは、 ドメイン＝ビジネスロジック http://www.?ickr.com/photos/wwworks/2222523486/
- 32. ドメインを戦い抜くための武器 ?オブジェクト指向分析／ 設計の基礎 ?GRASPパターン - 情報エキスパート - 高凝集 - 低結合 ?必要なのはDIコンテ ナ、ORM、RIA、NoSQLな どの知識ではない！
- 34. ありがとう ございました！