PofEAAで考えるSaaSバックエンドの作り方

Transcript

1. Making of SaaS Backend guided by PofEAA @dnskimox PofEAAで考える SaaSバックエンドの作り方

2. Who am I • Tanga Kenichi • @dnskimox • Backend

   Developer • SaaS for contract management 2 自己紹介

3. PofEAA The book about powerful design patterns for “Enterprise Application”

   written by Martin Fowler at 2002. 3 邦題：エンタープライズアプリケーションアーキテクチャ パターン

4. What is the “Enterprise application”? Enterprise application does: • store

   vary data • manage huge data • accept many requests at a time • collaborate with other Enterprise applications 4 エンタープライズアプリケーションとは

5. Enterprise Application ≒ Web Service 5 Especially a web service

   requiring massive development ほぼWEBサービスのこと

6. A web service of this session’s subject is... このセッションで取り上げる架空のWEBサービス ＊this

   service is fictitious MakeInvoice

7. Contents 7 About MakeInvoice The way we have managed such

   a large, complex application Architecture in MakeInvoice Service description about MakeInvoice, invoice creation and management SaaS Design patterns that will be worthwhile to adopt to MakeInvoice Adoptable Patterns 1 2 3 目次

8. 1. About MakeInvoice Service description about MakeInvoice, invoice creation and

   management SaaS MakeInvoiceについて

9. CloudSign Salesforce Dashboard(SPA) Client Service MakeInvoice

10. Simple Domain Model 素朴なドメインモデル

11. Slightly Complex Domain Model やや複雑なドメインモデル

12. More Complex Domain Model さらに複雑なドメインモデル

13. And More... さらにさらに

14. This logic has to consider: • difference between regular and

    discount item • tax calculation • to manipulate a template of document Invoice Creation 請求書生成のビジネスロジック

15. This logic has to consider: • partial payment • overpaying

    • carrying over to next month Reconciliation 入金消込のビジネスロジック

16. This logic has to consider: • resending invoice • how

    to handling old invoice • difference between total price and price paid partially Demand for Payment 支払催促のビジネスロジック

17. Combine and Split Invoice 請求書の結合と分割のビジネスロジック

18. Large domain model structure Complex business logic Requests from dashboard,

    from Salesforce, from other services using MakeInvoice Some other SaaS to have to connect 18 Characteristics　 of MakeInvoice backend API MakeInvoiceのバックエンドAPIの特徴

19. 2. Architecture in MakeInvoice The way we have managed such

    a large, complex application MakeInvoiceのアーキテクチャ

20. Clean Architecture

21. Domain Layer UseCase Layer Primary / Secondary Adapter Code for

    technical interest and implementation i.e: Http, gRPC, RDB, KVS Represents common use-cases using domain model Contains only “pure” domain concepts and logic Dependency direction 各レイヤーの責務 依存の方向性

22. Hexagonal architecture This architecture aims to: • receive request from

    variety of clients • reuse essential application code • write data on several data storages or send to other system 22 https://blog.tai2.net/hexagonal_architexture.html ヘキサゴナルアーキテクチャ

23. Hexagonal architecture • Primary Adapters are adapters to communicate with

    primary actor. • Secondary Adapters are adapters to communicate with supporting actor (also known as secondary actor). 23 https://blog.tai2.net/hexagonal_architexture.html プライマリアダプターと主アクター セカンダリアダプターと支援アクター

24. 3. Adoptable Patterns Design patterns that will be worthwhile to

    adopt to MakeInvoice 適用可能なパターン

25. Domain Layer UseCase Layer Primary / Secondary Adapter DataMapper, SingleTableInheritance,

    EmbeddedValue, SerializedLOB, DependentMapping, DataTransferObject, ServiceStub (Nothing) DomainModel, POJO, ValueObject, Repository レイヤー毎のパターン

26. Representing domain model is simple, unless domain classes depend on

    any library or framework. Domain Layer ドメインレイヤー

27. 会社、顧客、書類、請求書、請求書品目

28. “We wondered why people were so against using regular objects

    in their systems and concluded that it was because simple objects lacked a fancy name. ” 28 https://martinfowler.com/bliki/POJO.html Plain Old Java Object (POJO) 昔からある単なるJavaオブジェクト

29. case class Invoice ( id: DocumentId, companyId: CompanyId, customerId: CustomerId,

    items: Seq[InvoiceItem], billingDate: LocalDate, billingDueDate: LocalDate, status: InvoiceStatus ) extends Document abstract class Document { val id: DocumentId val companyId: CompanyId val customerId: CustomerId }

30. “An object model of the domain that incorporates both behavior

    and data.” 30 Domain Model https://www.martinfowler.com/eaaCatalog/domainModel.html ドメインモデル

31. case class Invoice ( id: DocumentId, companyId: CompanyId, customerId: CustomerId,

    items: Seq[InvoiceItem], billingDate: LocalDate, dueDate: LocalDate, status: InvoiceStatus ) extends Document { def totalPrice: Money = ??? def subtotal: Money = ??? def tax: Money = ??? def combine(other: Invoice): Invoice = ??? def split(prices: Seq[Money]): Seq[Invoice] = ??? }

32. “A small simple object, like money or a date range,

    whose equality isn't based on identity.” 32 Value Object https://www.martinfowler.com/eaaCatalog/valueObject.html 値オブジェクト

33. case class Money( currency: Currency, value: BigDecimal ) case class

    Currency( currencyCode: String )

34. case class Money( currency: Currency, value: BigDecimal ) { def

    plus(other: Money): Money = ??? def minus(other: Money): Money = ??? def mul(factor: BigDecimal): Money = ??? def div(factor: BigDecimal): Money = ??? }

35. case class Address( countryCode: CountryCode, zipCode: ZipCode, city: String, address1:

    String, address2: String ) { def isSame(other: Address): Boolean = ??? }

36. “Mediates between the domain and data mapping layers using a

    collection-like interface for accessing domain objects.” 36 https://www.martinfowler.com/eaaCatalog/repository.html Repository リポジトリ

37. 書類リポジトリ

38. trait DocumentRepository { def store[R :_trantask :_error](document: Document): Eff[R, Document]

    def resolve[R :_trantask :_error](id: DocumentId): Eff[R, Document] def matching[R :_trantask :_error](criteria: Criteria): Eff[R, Seq[Document]] } case class Criteria( companyId: Option[CompanyId], customerId: Option[CustomerId], documentType: Option[DocumentType] ) { def isSatisfiedBy(document: Document): Boolean = ??? }

39. What is EFF? 39 For more information, please go to

    Yoshimura‘s session. EFFについて

40. Design Domain Layer from Domain Model not from database. 40

    ドメインモデルから設計を始める

41. otherwise 41 さもないと

42. “By pulling all the behavior out into services, however, you

    essentially end up with Transaction Scripts, and thus lose the advantages that the domain model can bring. ” 42 https://martinfowler.com/bliki/AnemicDomainModel.html AnemicDomainModel ドメインモデル貧血症

43. This layer contains business transaction only. So meaningful patterns adopted

    here would be honestly nothing. UseCase Layer ユースケースレイヤー

44. class CreateDocumentUseCase @Inject() ( documentRepository: DocumentRepository, documentFactory: DocumentFactory ) {

    def execute[R :_trantask :_error]( documentType: DocumentType, ... ): Eff[R, Unit] = for { document <- documentFactory.create(documentType, ...) _ <- documentRepository.store(document) } yield () }

45. Secondary Adapter Main concern in this layer probably is mapping

    objects to/from relational database. Also clients to request to external service is in this layer. セカンダリアダプター

46. “A layer of Mappers that moves data between objects and

    a database while keeping them independent of each other and the mapper itself.” 46 https://www.martinfowler.com/eaaCatalog/dataMapper.html Data Mapper データマッパー

47. “An object that sets up a communication between two independent

    objects.” 47 https://www.martinfowler.com/eaaCatalog/mapper.html Mapper マッパー

48. Table schema is free from domain model. 48 テーブルスキーマは自由

49. Separation of Concerns 49 関心の分離

50. class DocumentRepositoryImpl { def store[R :_trantask :_error](document: Document): Eff[R, Document]

    = ??? def resolve[R :_trantask :_error](id: DocumentId): Eff[R, Document] = ??? def matching[R :_trantask :_error](criteria: Criteria): Eff[R, Seq[Document]] = ??? }

51. Impedance Mismatch 51 Object Oriented World • Abstraction • Composition

    Relational DB World • Set • Relation インピーダンスミスマッチ

52. Impedance Mismatch 52 Object Oriented World • Abstraction • Composition

    Relational DB World • Set • Relation 抽象化を集合と関係の世界へ

53. 抽象クラスの書類

54. “Represents an inheritance hierarchy of classes as a single table

    that has columns for all the fields of the various classes.” 54 https://www.martinfowler.com/eaaCatalog/singleTableInheritance.html Single Table Inheritance シングルテーブル継承

55. 書類テーブル

56. 書類の種類を増やす

57. 書類テーブル Ver.2

58. Many nullable fields! 58 Nullを許容するフィールドがたくさん

59. “Represents an inheritance hierarchy of classes with one table for

    each class.” 59 https://www.martinfowler.com/eaaCatalog/classTableInheritance.html Class Table Inheritance クラステーブル継承

60. 書類テーブル Ver.3

61. Impedance Mismatch 61 Object Oriented World • Abstraction • Composition

    Relational DB World • Set • Relation コンポジションを集合と関係の世界へ

62. 顧客に含まれる名前オブジェクト

63. “Maps an object into several fields of another object's table.”

    63 https://www.martinfowler.com/eaaCatalog/embeddedValue.html Embedded Value 組込バリュー

64. 顧客テーブル

65. 顧客に含まれる住所オブジェクト

66. x 1? 顧客テーブル Ver.2

67. “Saves a graph of objects by serializing them into a

    single large object (LOB), which it stores in a database field.” 67 https://www.martinfowler.com/eaaCatalog/serializedLOB.html Serialized LOB シリアライズドLOB

68. x ∞ 顧客テーブル Ver.3

69. Not bad 69 悪くない

70. But... 70 でも

71. • Managing scheme is difficult. • Adding and removing property

    is problematic. • Result of SQL is not human friendly. • Managing scheme is almost unnecessary. • New table is not needed. • Table joining does not occur. • Object count is unlimited. Using serialized field has pros and cons Pros Cons シリアライズされたフィールドの功罪

72. “Has one class perform the database mapping for a child

    class.” 72 https://www.martinfowler.com/eaaCatalog/dependentMapping.html Dependent Mapping 依存マッピング

73. x ∞ 顧客テーブル Ver.4 Dependent Object

74. • When owner object is updated, dependent objects are all

    deleted then re-inserted. • When owner object is deleted, dependent objects are deleted cascadingly. • Any object except for owner cannot associate with dependent object. • Dependent object's table has foreign key for owner's table. Dependent object's characteristic Association/Relation Update/Delete 依存オブジェクトの特徴

75. “Removes dependence upon problematic services during testing. WSDL ” 75

    https://www.martinfowler.com/eaaCatalog/dependentMapping.html Service Stub サービススタブ

76. クラウドサインサービス

77. Primary Adapter This layer is so-called "Presentation Layer". To parse

    request from client and to compose response are its responsibility. Also main App for running batch program is contained here. プライマリアダプター

78. “Provides a coarse-grained facade on fine-grained objects to improve efficiency

    over a network.” 78 https://www.martinfowler.com/eaaCatalog/remoteFacade.html Remote Facade

79. class DocumentController @Inject() ( createDocumentUseCase: CreateDocumentUseCase, getDocumentUseCase: GetDocumentUseCase ) extends

    AkkaHttpController { def routes: Route = pathPrefix("DocumentService") { post { path("CreateDocument") { createDocument } ~ path("GetDocument") { getDocument } } } private def createDocument: Route = ??? private def getDocument: Route = ??? }

80. Split endpoints moderately coarse grained. 80 荒い粒度でエンドポイントを分割する

81. “An object that carries data between processes in order to

    reduce the number of method calls.” 81 https://www.martinfowler.com/eaaCatalog/dataTransferObject.html Data Transfer Object データ変換オブジェクト

82. ドキュメントアセンブラ ドキュメントDTO

83. DTO structure is free from domain model. 83 DTOの構造は自由

84. Separation of Concerns 84 関心の分離

85. Domain Model Repository ValueObject DataMapper SingleTableInheritanse ClassTableInheritanse EmbededValue SerializedLOB DependentMapping

    DTO Remote Facade Putting It All Together 全てのパターンをひとつに SPA DB UseCase Service Stub Other SaaS

86. Conclusion 86 PofEAA put forward many useful patterns for complex

    web application. But , as Fowler writes, these patterns have pros and cons. So we have to keep thinking which patterns to use or not use any pattern. Use this advice to prod your thinking. In the end you have to make, and live with, the decisions yourself. One good thing is that your decisions are not cast forever in stone. - Martin Fowler 結論

87. Now, you have learned main concept to write code of

    　　　　　backend. 87 もうScalebaseのバックエンドを書けるはず

88. Join us! ご応募お待ちしております！

89. Does anyone have any questions? @dnskimox dnskimox.hateblo.jp 89 Thanks! ご清聴ありがとうございました！

90. Reference literature • https://www.amazon.co.jp/dp/B008OHVDFM • https://www.martinfowler.com/eaaCatalog/index.html • https://bliki-ja.github.io/pofeaa/CatalogOfPofEAA_Ja/ • https://martinfowler.com/bliki/POJO.html

    • https://martinfowler.com/bliki/AnemicDomainModel.html • https://blog.tai2.net/hexagonal_architexture.html • http://atnos-org.github.io/eff/index.html • https://github.com/google/guice 90 参考文献