In the functional paradigm, language constraints aside, to model this "story" would need these:
- The definition of Account
- The definition of Customer
- A ledger consisting of:
List of Account,
List of Customer,
List of Account-Customer relations
A clerk works on the records on the ledger with one hand and one pen, a metaphor for the service process working on the data in the database.
An act, such as money transfer, would be described as a function.
A customer creating a new account for himself is written as `fn createAccount(Customer, NewAccountData)` because from the perspective of the clerk/bank manager/service the customer, newAccountData, and the existing data in the ledger as objects which the clerk/bank manager/service must move around in a precise way.
The module which has 'fn createAccount` depends on the types `Account` and `Customer`.
In english it roughly sounds like,
"the success of writing the rule of creating an account for a customer depends on knowing the definition of Account and Customer."
The function is not written as `customer.accountService.createAccount(newAccountData)`, because the clerk doesn't schizophrenically pretend to be the customer and create an account for himself. The clerk just receive request from the actual customer, writes new account entry and customer-account-relation entry into the ledger, that's it.
There's simply no need to call CustomerService from AccountService and vice versa. There's no need for reflections because data types are all available at compile time.
Oh, I meant to emphasis on that "customerService depends on accountService and vice versa" thingy. While in my writings "accountService is a member of customer" is a form of customer depending on accountService.
But my main point is that it should not be written that way at all.
Semantically, if we must include the subject, it should be
Or replace theService with CustomerAccountService or whatever.
Writing that way, with functions depending on types, avoid getting tangled from the so-called account-customer cyclical dependencies. Because account and customer don't need to know each other until a function needs to know both of them. There's no such thing as `customer.getAccounts()` because in the end the query would roughly look like `getAccountsWhereCustomerIs(CustomerId)`.
You're not dumb. It's just me mis-writing due to the fact that I'm writing this at 4 in the morning lol. Or maybe I'm misinterpreted parent comment and that confuses you. In that case, I'm the dumb.
- The definition of Account
- The definition of Customer
- A ledger consisting of: List of Account, List of Customer, List of Account-Customer relations
A clerk works on the records on the ledger with one hand and one pen, a metaphor for the service process working on the data in the database.
An act, such as money transfer, would be described as a function.
A customer creating a new account for himself is written as `fn createAccount(Customer, NewAccountData)` because from the perspective of the clerk/bank manager/service the customer, newAccountData, and the existing data in the ledger as objects which the clerk/bank manager/service must move around in a precise way.
The module which has 'fn createAccount` depends on the types `Account` and `Customer`.
In english it roughly sounds like,
"the success of writing the rule of creating an account for a customer depends on knowing the definition of Account and Customer."
The function is not written as `customer.accountService.createAccount(newAccountData)`, because the clerk doesn't schizophrenically pretend to be the customer and create an account for himself. The clerk just receive request from the actual customer, writes new account entry and customer-account-relation entry into the ledger, that's it.
There's simply no need to call CustomerService from AccountService and vice versa. There's no need for reflections because data types are all available at compile time.