ビジネスロジック
実装進化論
2010年10月27日
佐藤 匡剛
http://ameblo.jp/ouobpo
An Evolution of Business Logic Implementation
• 仕事
- Software AG株式会社
グローバルコンサルタンシー
サービス
webMethodsコンサルタント
- 書籍の執筆/翻訳など
• Web
- ブログ: http://ameblo.jp/ouobpo
- Twitter: t...
『プログラミングScala』年明け発売!
日本語版
Domain Modelパターン
は難しい?
http://www.martinfowler.com/eaaCatalog/domainModel.html
Domain Modelパターンは...
•実在する
•超人的なマジックではない
•ビジネスロジック実装の試行錯誤の中で自然
に り着く道である
プログラマ黎明期
http://www.flickr.com/photos/nickhubbard/2878833485/
#!/usr/bin/env perl
use strict;
use CGI::Carp qw(fatalsToBrowser);
require ‘util.pl’
my %FORM = util::read_form('POST', 'u...
Perl/CGI
order.pl
DB
ファイル
ビジネス
ロジック
HTML
データ
アクセス
public class OrderServlet extends HttpServlet {
protected void service(
HttpServletRequest request,
HttpServletResponse re...
Servlet/JSP
OrderServlet
DB
XML
ビジネス
ロジック
データ
アクセス
/order/confirm.jsp
HTML
レイヤアーキテクチャ
の発見
http://www.flickr.com/photos/bloggingbookshelf/5084749109/
ドメイン層 データアクセス層プレゼン層
Transaction Script
DB
アクション
アクション
アクション
アクション
サービス
(ユースケースA)
サービス
(ユースケースB)
サービス
(ユースケースC)
サービス
(ユースケー...
public class ProcessOrderServiceImpl
implements IProcessOrderService {
private IOrderDao fOrderDao;
private ICustomerDao f...
Transaction Script
• プレゼン、ビジネスロジック、データアクセ
スの各層は分離される
• ビジネスロジックはユースケース単位で構成さ
れる
× ビジネスロジックが複雑になると、コード重
複の制御が難しくなる
Table Module
ドメイン層 データアクセス層プレゼン層
DB
アクション
アクション
アクション
アクション
サービス
(ユースケースA)
サービス
(ユースケースB)
サービス
(ユースケースC)
サービス
(ユースケースD)
DA...
public class ProcessOrderServiceImpl
implements IProcessOrderService {
private IOrderLogic fOrderLogic;
private ICustomerL...
public class OrderLogicImpl
implements IOrderLogic {
private IOrderDao fOrderDao;
private ICustomerLogic fCustomerLogic;
p...
Table Module
• プレゼン、ビジネスロジック、データアクセ
スの各層は分離される
• ビジネスロジックはさらに2層に分かれる
- Service Layer = ユースケース単位
- ドメインロジック = DBテーブル単位
• 実用...
キャズムを超える
http://www.flickr.com/photos/matheus_momesso/4469788827/
総称関数(CLOS)
;;; クラス定義
(defclass order ()
((number :accessor order-number ...)))
(defmethod confirm ((self order))
(... (ord...
confirm(order);
order.confirm();
総称関数 → オブジェクト
class OrderLogic {
static void confirm(
OrderBean order,
CustomerBean customer) {
order.getOrderNo();
...
Or...
Domain Model
ドメイン層 データアクセス層プレゼン層
DB
アクション
アクション
アクション
アクション
サービス
(ユースケースA)
サービス
(ユースケースB)
サービス
(ユースケースC)
サービス
(ユースケースD)
OR...
public class ProcessOrderServiceImpl
implements IProcessOrderService {
private IOrderRepository fOrderRepository;
private ...
public class Order {
private Customer fCustomer;
public void confirm() {
...
}
public void process() {
...
}
public void c...
Domain Modelのメリット
• 再利用性、メンテナンス性が高くなる
• ロジックの置き場に悩まない
• 複雑なビジネスロジックをモデルによって
可視化できる
• コードの字面がシンプルになり、美しい
まとめ
•コードの重複排除を追究すると、自然
とTable Moduleまで り着く
•Table Moduleが総称関数によるOOの実
装と気づけば、Domain Modelへの道が
拓ける
最後に
“Architecture teams must not siphon
off all the best and brightest.”
アーキテクチャチームに
最も優秀なメンバ
を集めてはいけない。
— Eric Evans, Domain-...
テクノロジからドメインへ
• テクノロジの活用に忙殺されてい
ないだろうか?
- 顧客に価値をもたらすのはイン
フラやフレームワークではない
• ビジネスに真の力を与えるのは、
ドメイン=ビジネスロジック
http://www.flickr.co...
ドメインを戦い抜くための武器
•オブジェクト指向分析/
設計の基礎
•GRASPパターン
- 情報エキスパート
- 高凝集
- 低結合
•必要なのはDIコンテ
ナ、ORM、RIA、NoSQLな
どの知識ではない!
ドメインで皆さんの
力を発揮しよう!
ありがとう
ございました!
Upcoming SlideShare
Loading in …5
×

ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation

6,298 views
6,240 views

Published on

DevLove 2010/10/27 発表資料。

Published in: Technology
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,298
On SlideShare
0
From Embeds
0
Number of Embeds
79
Actions
Shares
0
Downloads
37
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation

  1. 1. ビジネスロジック 実装進化論 2010年10月27日 佐藤 匡剛 http://ameblo.jp/ouobpo An Evolution of Business Logic Implementation
  2. 2. • 仕事 - Software AG株式会社 グローバルコンサルタンシー サービス webMethodsコンサルタント - 書籍の執筆/翻訳など • Web - ブログ: http://ameblo.jp/ouobpo - Twitter: tadayosi • 趣味 - Kindleで読書 - 日本ベジタリアン協会会員 佐藤 匡剛(さとう ただよし) http://www.flickr.com/photos/robertnyman/189691155/
  3. 3. 『プログラミングScala』年明け発売! 日本語版
  4. 4. Domain Modelパターン は難しい?
  5. 5. http://www.martinfowler.com/eaaCatalog/domainModel.html
  6. 6. Domain Modelパターンは... •実在する •超人的なマジックではない •ビジネスロジック実装の試行錯誤の中で自然 に り着く道である
  7. 7. プログラマ黎明期 http://www.flickr.com/photos/nickhubbard/2878833485/
  8. 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
  9. 9. Perl/CGI order.pl DB ファイル ビジネス ロジック HTML データ アクセス
  10. 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) { // ビジネスロジック? ... } ...
  11. 11. Servlet/JSP OrderServlet DB XML ビジネス ロジック データ アクセス /order/confirm.jsp HTML
  12. 12. レイヤアーキテクチャ の発見 http://www.flickr.com/photos/bloggingbookshelf/5084749109/
  13. 13. ドメイン層 データアクセス層プレゼン層 Transaction Script DB アクション アクション アクション アクション サービス (ユースケースA) サービス (ユースケースB) サービス (ユースケースC) サービス (ユースケースD) DAO DAO DAO
  14. 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. 15. Transaction Script • プレゼン、ビジネスロジック、データアクセ スの各層は分離される • ビジネスロジックはユースケース単位で構成さ れる × ビジネスロジックが複雑になると、コード重 複の制御が難しくなる
  16. 16. Table Module ドメイン層 データアクセス層プレゼン層 DB アクション アクション アクション アクション サービス (ユースケースA) サービス (ユースケースB) サービス (ユースケースC) サービス (ユースケースD) DAO DAO DAO ロジック (テーブルX) ロジック (テーブルY) ロジック (テーブルZ)
  17. 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. 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. 19. Table Module • プレゼン、ビジネスロジック、データアクセ スの各層は分離される • ビジネスロジックはさらに2層に分かれる - Service Layer = ユースケース単位 - ドメインロジック = DBテーブル単位 • 実用レベルでは問題ないが、コードにムダが 多く美しくない
  20. 20. キャズムを超える http://www.flickr.com/photos/matheus_momesso/4469788827/
  21. 21. 総称関数(CLOS) ;;; クラス定義 (defclass order () ((number :accessor order-number ...))) (defmethod confirm ((self order)) (... (order-number self))) ;;; 実行コード (setq o (make-instance ‘order :number 12345)) (confirm o)
  22. 22. confirm(order); order.confirm();
  23. 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
  24. 24. Domain Model ドメイン層 データアクセス層プレゼン層 DB アクション アクション アクション アクション サービス (ユースケースA) サービス (ユースケースB) サービス (ユースケースC) サービス (ユースケースD) ORM ORM ORM ドメイン オブジェクト ドメイン オブジェクト ドメイン オブジェクト
  25. 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. 26. public class Order { private Customer fCustomer; public void confirm() { ... } public void process() { ... } public void cancel() { ... } ...
  27. 27. Domain Modelのメリット • 再利用性、メンテナンス性が高くなる • ロジックの置き場に悩まない • 複雑なビジネスロジックをモデルによって 可視化できる • コードの字面がシンプルになり、美しい
  28. 28. まとめ •コードの重複排除を追究すると、自然 とTable Moduleまで り着く •Table Moduleが総称関数によるOOの実 装と気づけば、Domain Modelへの道が 拓ける
  29. 29. 最後に
  30. 30. “Architecture teams must not siphon off all the best and brightest.” アーキテクチャチームに 最も優秀なメンバ を集めてはいけない。 — Eric Evans, Domain-Driven Design
  31. 31. テクノロジからドメインへ • テクノロジの活用に忙殺されてい ないだろうか? - 顧客に価値をもたらすのはイン フラやフレームワークではない • ビジネスに真の力を与えるのは、 ドメイン=ビジネスロジック http://www.flickr.com/photos/wwworks/2222523486/
  32. 32. ドメインを戦い抜くための武器 •オブジェクト指向分析/ 設計の基礎 •GRASPパターン - 情報エキスパート - 高凝集 - 低結合 •必要なのはDIコンテ ナ、ORM、RIA、NoSQLな どの知識ではない!
  33. 33. ドメインで皆さんの 力を発揮しよう!
  34. 34. ありがとう ございました!

×