Looking at the marbles example from the fabric samples, specific at the node.js version of the chaincode in the marbles_chaincode.js file, the function async getAllResults(iterator, isHistory) is clearly a helper function and not an actual transaction (at least this is what I could understand from looking at the code). Which functions are proper transactions and which are just helper methods?
you are correct, getAllResults is just a helper function. This particular example isn't the best sample in the world and doesn't obviously distinguish which are transactions that can be called and which are helper methods. You need to understand the code to determine which are transactions. For example because the code uses a generic dispatcher implementation call the right method from an invoke you can eliminate all methods that don't follow the exact same signature of (stub, args, thisClass) then it isn't meant to be externally called. However that doesn't guarantee this but helps to at least provide an initial subset
For actual transactions, we have to use stub.putState so that we can update the ledger. For query any data we have to use stub.getState where query is not considered as transaction because there is no update in ledger due to query.
So in Hyperledger Fabric, transactions are happened with the changes of world state of ledgers or invoking the chaincode and so we use stub.putState to put new information on ledger.
So if you find stub.putState in any function, you can consider that function as proper transaction function.
Related
How a chaincode consist with multiple smart contracts in go lang? for the go only has one main function.
When it comes to Go chaincode, there can be any number of smart contracts. There are 3 main functions:
Init: called on instantiation or upgrade of the chaincode. It is usually used to initialise data.
Invoke: called on every transaction. In this function, you can define which functions are called when some particular arguments are passed, thus, making it possible to have multiple smart contracts in one go file.
main: It starts the chaincode in a container on instantiating it.
Here is a detailed tutorial explaining how to write Go smart contracts: https://hyperledger-fabric.readthedocs.io/en/release-2.0/chaincode4ade.html#vendoring
I need to split my business logic into two Smart Contracts, A and B, where A adds some data on the ledger and B read's A's data directly from the ledger, for some calculation.
I need this split because:
A and B will have different endorsement policies
B's calculation transaction security should rely on "read-set" mechanism for validation, which I know is enforced for data that B reads directly from the ledger but I'm not sure for data read from a cross-chaincode call (and I can't find info about it)
So...
The guide says
Multiple smart contracts can be defined within the same chaincode. When a chaincode is deployed, all smart contracts within it are made available to applications.
But I really can't find a reference on how to bundle multiple Smart Contracts into a single Chaincode (necessary thing in order to let B read A's data).
The best for my project would be having A and B in different languages (respectively, Javascript and Java) but if they need to be written in the same language to fit in the same chaincode I could rewrite the first one.
...
Can somebody help me? I actually just need a reference to explain me how to bundle multiple Smart Contracts into a Chaincode (
or an example, couldn't find that either)
I am designing a CQRS application using DDD, and am wondering how to implement the following scenario:
a Participant aggregate can be referenced by multiple ParticipantEntry aggregates
an AddParticipantInfoCommand is issued to the Command side, which contains all info of the Participant and one ParticipantEntry (similar to an Order and one OrderLineItem)
Where should the logic be implemented that checks whether the Participant already exists and if it doesn't exist, creates the Participant?
Should it be done in a Saga that first checks the domain model for the existence of the Participant, and if it doesn't find it, issues an AddParticipantCommand and afterwards an AddParticipantEntry command containing the Participant ID?
Should this be done entirely by the aggregateroots in the domain model itself?
You don't necessarily need sagas in order to deal with this situation. Take a look at my blog post on why not to create aggregate roots, and what to do instead:
http://udidahan.com/2009/06/29/dont-create-aggregate-roots/
Where should the logic be implemented that checks whether the Participant already exists and if it doesn't exist, creates the Participant?
In most instances, this behavior should be under the control of the Participant aggregate itself.
Processes are useful when you need to coordinate changes across multiple transaction boundaries. Two changes to the same aggregate, however, can be managed within the same transaction.
You can implement this as two distinct transactions operating on the same aggregate, with coordination; but the extra complexity of a process doesn't offer any gains. It's much simpler to send the single command to the aggregate, and allow it to decide what actions to take to maintain the correct invariant.
Sagas, in particular, are a pattern for reverting multiple transactions. Yan Cui's How the Saga Pattern manages failures with AWS Lambda and Step Functions includes a good illustration of a travel booking saga.
(Note: there is considerable confusion about the definition of "saga"; the NServiceBus community tends to understand the term a slightly different way than originally described by Garia-Molina and Salem. kellabyte's Clarifying the Saga Pattern surveys the confusion.)
I have several aggregates: Deposit, Withdraw etc. Now there is a VO called Ledger, which has other related VOs as well. Ledger marks the transaction for both the Deposit and Withdraw, which ever takes place. In this case, it seems similar to making a separate aggregate(creating a folder and placing Ledger and related types into it). But DDD won't allow me that, because Aggregate roots can only be Entities.
What can be the possible solution for it? How can I categorize and place Ledger and related VOs while staying in the boundaries of DDD?
UPDATE:
The ledger is like a record, a transaction for each operation performed. For example, when a deposit has been made, a trade has occurred etc. So it has no state, and will be just saved once and never modified again. It is persisted for record keeping purposes.
Deposit and Withdraw both have states and a lifetime, their status will change from Pending to Confirmation, or from Pending to Cancelled. So they cannot be services.
Please let me know if more information is required.
Thanks in advance.
From your update, it sounds as though you might have a slight terminology issue and a missing entity.
You might need to rename your Ledger value object to LedgerRecord or LedgerEntry.
Your missing entity might then be a Ledger (a ledger is like a book, a container of records or entries). This would have a collection of LedgerRecords.
So you would then maybe call Ledger.MakeEntry(text) or maybe call LedgerService.GetLedgerSectionByDateRange(from, to), which would return a Ledger populated with LedgerRecords from that date range, etc.
First, think of the rest of VOs that are part of the Ledger. Is there any hidden identity that you haven't considered before among these VOs? In that case, that would be the (root) Entity and you would have your Aggregate.
If that's not the case, you could consider whether the Ledger is a VO that is part of an Aggregate in which the root entity is Operation, where Operation is an Entity with unique identity and Withdraw and Deposit would be specializations of it.
As I understand it, a UnitOfWork class is meant to represent the concept of a business transaction in the domain. It's not directly supposed to represent a database transaction, which is a detail of only one possible implementation.
Q: So why does so much documentation about the Unit of Work pattern refer to "Commit" and "Rollback" methods?
These concepts mean nothing to the domain, or to domain experts. A business transaction can be "completed", and therefore the UnitOfWork should provide a "Complete" method. Likewise, instead of a "Rollback" method, shouldn't it be modeled as "Clear"?
Update:
Answer: Both answers below are correct. Their are two variants of UoW: object registration and caller registration. In object registration, Rollback serves to undo changes to all in-memory objects. In caller registration, Rollback serves to clear all recorded changes such that subsequent call to Commit will do nothing.
The Unit of Work design pattern, at least as defined by Fowler in Patterns of Enterprise Application Architecture - is an implementation detail concerning object-relational persistence mapping. It is not an entity defined in Evans' Domain Driven Design.
As such, it should neither be part of the business discussion, nor an entity that's directly exposed in a domain model - perhaps excepting the commit() method. Instead its intent is tracking "clean" and "dirty" business entities - the objects from a domain model exposed to clients. The purpose is allowing multiple interactions - in web context requests - with a domain model without the need to read and write from persistence (usually a database) each time.
Business entities call it when their methods are called. When their state is altered, they register themselves as dirty with the Unit of Work. Then the Unit of Work's commit() handles the entire persistence transaction in terms of writing out the object graph and rollback() means restoring the state of entities to what they were. So its very much the implementation leaking through to the "abstraction", but its intent is very clear.
On the other hand, "Undo" and "Complete" don't necessarily map one-to-one with this definition. An "Undo" or "Clear" may only rollback an object graph partially for instance depending on the business context. While "Complete" may well be altering state on some entity as well as committing the graph. As such I would put these methods, with business meaning, on a Service Layer or Aggregate Root object.
I agree. My guess is that it uses the terms "Rollback" and "Commit" because they are indeed known terms (and do reveal intent, especially to programmers). However I think that it would be more correct to use the term "Complete". With regards to "Clear" I'm not as inclined to agreeing with you. I don't think that any domain expert would agree that you "Clear" a business transaction. "Undo" is a more suitable term in my opinion.