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.

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

10. Minimal Distributed System
Architecture
Services
Database
User
Interface
Application

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

16. AccountService calling TxnService
GetTransactions(acc1)
GetTransactions(acc2)
GetTransactions(acc3)
GetTransactions(acc4)

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

25. Service Contract Design

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
}

29. Possible starting dates
03/11/2010
03/11/10
03-11-2010
03-11-10
03-Nov-2010
3-Nov-10

30. Possible customer id
008675100004664
100004664
8675100004664
CC008675100004664

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?

44. Web Services
Database
User
Interface
Application
Data
Transfer
Objects
UI Model
Domain
Model
OR
Mapping
objects
Hibernate

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!