Service Architecture patterns
Download as PPTX, PDF0 likes318 views
The document discusses various service architecture patterns for designing microservices. It covers concepts like service responsibilities, data ownership-driven services, shared data services, service contracts, and decoupling domain entities from contracts. Some key points discussed are: - Services should have well-defined responsibilities and own the data for their domain. - Data ownership allows independent deployment but can result in performance issues due to many calls between services. - Shared data services improve performance but reduce independence and blur domain boundaries. - Service contracts should be designed for external use rather than as an implementation detail, and should loosely couple with domain models. - Domain models can be shared between services but contracts need to encapsulate domain entities to control serialized data.
Service Architecture patterns
- 1. Service Architecture Patterns Avinash Chugh Vivek Singh Rohith Rajagopal
- 2. Designs are neither good nor bad. They are more or less useful. Martin Fowler
- 3. Service = SOA service External Interface Interface contracts Maps service contracts to/from domain entities Interacts with DDD services Cross functional responsibility
- 5. SOA Services Services Mappers Service Contract Persistence Mappings Repositories get client requests as request/response with domain objects Factories Entities Value Objects Aggregates Domain Model find domain objects orchestrates business logic read/write data source send request contract to find/save domain objects
- 6. Service = DDD Service Core business logic Orchestrates domain layer Reusable within a SOA service
- 7. Simple Banking Application Customer(1)----(*)Account(1)----(*)Transaction Opening an account View transactions across accounts Account Summary Customer Profile Perform transaction
- 9. Service Responsibility Partition Breaking system into different services
- 11. Grows to monolithic services Single database Everything gets deployed every time Test everything every time Need for smaller sub-systems
- 12. Database Domain Model Service A Database Domain Model Service B Database Domain Model Service C Database Domain Model Service D Data Ownership Driven Services
- 13. Advantages Development decoupling Independent evolution Deployment independence Low testing cost
- 14. Disadvantages
- 15. Inner loop problem/N+1 problem Database Domain Model Account Service Database Domain Model Transaction Service Customer Acc 1 Acc2 Acc4 Acc3 Txn1 Txn2 Txn3 Txn1 Txn5 Txn1 Txn2 Txn1
- 17. Batch Request Interface GetTransactions(acc1, acc2, acc3, acc4) Use correlation ids instead of order Doesn’t solve all problems
- 18. Transaction Atomicity Database Domain Model Service A Database Domain Model Service C Customer New Acc Txn1
- 19. Transaction No transaction between service operations Distributed transaction has performance issues
- 20. Database Domain Model Service A Domain Model Service C Domain Model Service B Domain Model Service D Shared Data Services Database Database
- 21. Advantages Easier resolution of performance issues Transaction support Development still quite independent
- 22. Disadvantages Unclear domain boundaries Fuzzy ownership of data Code duplication across services
- 23. Tradeoffs Code duplication Model duplication Transactions Service Independence Performance Data Ownership vs
- 26. By design & not by side-effect Service is a product Contract is user interface for service Can help in multi-version capability
- 27. Banking application contract class OpenAccountRequest { int CustomerId; DateTime StartingDate; AccountType AccountType; Name AccountHolderName; } class Name { string FirstName; string LastName; } enum AccountType { Savings, Current }
- 28. class OpenAccountRequest { string CustomerId; string StartingDate; string AccountType; Name AccountHolderName; } class Name { string FirstName; string LastName; } class OpenAccountRequest { int CustomerId; DateTime StartingDate; AccountType AccountType; Name AccountHolderName; } class Name { string FirstName; string LastName; } enum AccountType { Savings, Current }
- 31. Service Serve as much as possible
- 32. class OpenAccountRequest { string CustomerId; string StartingDate; string AccountType; string AccountHolderFirstName; string AccountHolderLastName; } class OpenAccountRequest { string CustomerId; string StartingDate; string AccountType; Name AccountHolderName; } class Name { string FirstName; string LastName; } Business doesn’t understand objects
- 33. ….and definitely not class inheritance class OpenJointAccountRequest : OpenAccountRequest { int AccountNumber; } class OpenAccountRequest { string CustomerId; string StartingDate; string AccountType; string AccountHolderFirstName; string AccountHolderLastName; } class OpenAccountRequest { string CustomerId; string StartingDate; string AccountType; string AccountHolderFirstName string AccountHolderLastName string JointAccountNumber; }
- 34. Use flat structure, no nested objects Nested objects only when using list Business Readable Contract
- 35. Service operations are not methods public interface PaymentGatewayService { bool Authorize(string cardNumber, string verifiedByVisaPassword); bool Validate(string cardNumber, string holderName, string cvv); bool PerformTransaction(string cardNumber, string holderName, string cvv, decimal amount } interface PaymentGatewayService { CreditCardPaymentResponse Process(CreditCardPaymentRequest request); }
- 36. class CreditCardPaymentRequest { string CardNumber; string CVVNumber; string VBVPassword; string HolderName; string Amount; } class CreditCardPaymentResponse { string ErrorCode; string ErrorDescription; string TransactionReferenceNumber; } No parameters/return-value/exception
- 38. Late Binding over Fail fast Service side validation over schema validation Loose types over strong types Error message over system exceptions Also useful in versioning
- 40. Decouple Domain Entities and Service Contract
- 41. Web Services Database User Interface Application Data Transfer Objects UI Model Domain Model Extremely Common Architecture OR Mapping objects
- 42. Writing different data definition and mapping them Can be quite tedious and error prone
- 43. What can we do?
- 45. How about?
- 46. Web Services Database User Interface Application Domain Model Domain Model Domain Model Hibernate Data Transfer Objects UI Model Shared Domain Model
- 47. public class Customer { int id; Name name; int age; IList<Account> accounts; } public class Account { int id; string number; DateTime openingDate; DateTime closingDate; decimal balance; IList<Transaction> transactions; } public class Transaction { int id; DateTime date; decimal amount; TransactionType type; } public enum TransactionType { Credit, Debit } public class Name { string first; string middle; string last; string title; } Domain Model
- 48. public class Customer { int id; string firstName; string middleName; string lastName; string title; int age; } public class Customer { int id; Name name; int age; } public class Name { string first; string middle; string last; string title; } Domain Model Contract Can tolerate this
- 49. public class Customer { string id; string firstName; string middleName; string lastName; string title; string age; } public class Customer { int id; Name name; int age; } public class Name { string first; string middle; string last; string title; } Contract …even this Domain Model
- 50. public class Customer { int id; int customerId; string firstName; string middleName; string lastName; string title; int age; } public class Customer { int id; int customerId; string firstName; string middleName; string lastName; string title; int age; } Contract Encapsulate service internals Domain Model
- 51. public class Customer { public string CustomerId { get; set; } public string FirstName { get; set; } public string MiddleName { get; set; } public string LastName { get; set; } public string Title { get; set; } public string Age { get; set; } } public class Customer { int customerId; string firstName; string middleName; string lastName; string title; int age; } Encapsulate Domain Model Contract Domain Model
- 52. public class Customer { public string CustomerId { get; set; } public string FirstName { get; set; } public string MiddleName { get; set; } public string LastName { get; set; } public string Title { get; set; } public string Age { get; set; } } public class Customer { int id; int customerId; Name name; int age; } public class Name { string first; string middle; string last; string title; Too much mismatch Contract Domain Model
- 53. Bad contract and domain
- 54. public class CustomerService { private readonly CustomerRepository customerRepository; public CustomerService(CustomerRepository customerRepository) { this.customerRepository = customerRepository; } public Customer Get (CustomerServiceRequest request) { try { return customerRepository.LoadCustomer(request. Identification); } finally { customerRepository.Dispose(); } } } Simple Service Implementation
- 55. public class Customer { Name name; int age; } public class Customer { Name name; IList<Account> accounts; } public class Account { decimal balance; IList<Transaction> transactions; } public class Transaction { int id; DateTime date; decimal amount; TransactionType type; } public class Customer { Name name; IList<Account> accounts; } public class Account { string number; decimal balance; } Customer Profile Accounts Summary Transactions Since
- 56. No control over data sent
- 57. <?xml version="1.0" encoding="utf-8" ?> <hibernate-mapping > <class name="Customer" table="Customers" lazy="true"> <id name="Id"> <column name="Id" not-null="true" /> <generator class="identity" /> </id> <bag name="accounts" lazy="true" cascade="all-delete-orphan" access="field"> <key column="CustomerId" /> <one-to-many class="Account"/> </bag> </class> <class name="Account" table="Accounts" lazy="true"> <id name="Id"> <column name="Id" not-null="true" /> <generator class="identity" /> </id> </class> </hibernate-mapping>
- 58. Serializing lazy domain object Create Session Load Customer Return Customer Close Session Get Customer Customer Response
- 59. Lazy entities not loaded Account 2 Id Balance Account 1 Id Balance Customer Id Name Age
- 60. hacks… <?xml version="1.0" encoding="utf-8" ?> <hibernate-mapping > <class name="Customer" table="Customers" lazy=“false"> <id name="Id"> <column name="Id" not-null="true" /> <generator class="identity" /> </id> <bag name="accounts" lazy=“false" cascade="all-delete-orphan" access="field"> <key column="CustomerId" /> <one-to-many class="Account"/> </bag> </class> <class name="Account" table="Accounts" lazy=“false"> <id name="Id"> <column name="Id" not-null="true" /> <generator class="identity" /> </id> </class> </hibernate-mapping>
- 61. isn’t this smart public Customer Get(CustomerIdentification customerIdentification) { try { Customer customer = customerRepository.LoadCustomer(customerIdentification); ForceLoad(customer); return customer; } finally { customerRepository.Dispose(); } } private void ForceLoad(Customer customer) { customer.ToString(); customer.Accounts.ForEach(account => account.ToString()); //.....so on }
- 62. no…may be should have used reflection
- 63. Tradeoffs Code reuse Less code Mapping simplicity Design compromise Decoupling Control serialized data Performance vs
- 65. Thank you!
Editor's Notes
- #7: Webservices get requests from the client, converts them to domain objects with the help of mappers/repositories, call services with these domain objects, these services orchestrate the domain logic and they will use the repository to write to the database
- #12: monolithic architecture diagram (also draw front end box) test, deploy....no decoupling....small pieces, easier to understand, can be worked upon independently.
- #17: Customer/Accounts and Transactions. Caching, batched request might work. Sometimes join at database level is the only resolution.
- #21: Opening account with starting balance. AccountService and TransactionService
- #25: Multiple domain representation Need to fix write ownership Services coupling via database
- #54: We haven’t used sub-classes
- #65: Accidental or essential
- #70: Add more members
- #71: Need code sample for Dynamic Proxy here.
- #76: I still have duplication. And I have to modify my equals method to look at any new members added – this is error prone. Equals might have a specific meaning – Id equality for example. Use a method like MemberEquals.
- #77: Complicated to implement – with lists, nested objects.
- #78: Easy to implement. Memory intensive if you have a deep object graph - Avoid deep object graphs on the UI. Or clone only that portion of the object graph which is different – problem: You’ll need a special equals which you have to keep in sync when new members are added, etc.
- #80: Should this be CLOBs and/or BLOBs in the DB?
- #86: If the XML Schema changes or if the Class definition changes. When could you use it: if the data is stored only for reference (eg:. Quotes from the quoting engine are valid for 30 days if the accompanying XML response is stored untampered for that period) - probably store the digitally signed message from the other system. Might consider also storing the data in a normalised form if you need to do anything else with it. Storing presentations/attachments - if the object is really large, consider moving it out of the DB and on to the file system with a reference to the location. Problem with this is that you are trading off the DB performance/size with consistency issues and more complexity dealing with two different places where the truth is stored. pros: performance and development simplicity Eg: Insurecom - we were getting XML from a quoting engine. Had to update the XML with new values and send it across. The logic to do this became fairly painful even tho' we only had to update a couple of places in the XML. Also we only ever had to deal with one policy at a time - the user never wanted to deal with all the policies which have a risk rating above 0.8 in one shot, etc.
- #87: Eg. Quotes from a quoting engine are valid for 30 days if the accompanying XML response is stored untampered for that period – you probably want to store the message signed by the quoting engine’s private key in your DB as a BLOB. If the blob is really large, consider storing it outside the DB with a link to the location.
- #89: Should this be CLOBs and/or BLOBs in the DB?