I am new into blockchain technology and I'd like to start my project with product authentication. I am curious if it would be good choice to make use of it.
For example lets say I got some real physical products and I want to check their originality. They got their unique serial number or attached electronic identifier (RFID for example).
According to this simple python blockchain: https://medium.com/crypto-currently/lets-build-the-tiniest-blockchain-e70965a248b
In the block class
class Block:
def __init__(self, index, timestamp, data, previous_hash):
self.index = index
self.timestamp = timestamp
self.data = data
self.previous_hash = previous_hash
self.hash = self.hash_block()
We would create new block every time some product will be scanned (for example by phone). What info should be in data then? Product name, serial number, action type?
At the start, right after all the products have been created, everyone will be initial scanned. So for example for 100 first initial products and theirs scans, there would be 100 blocks in blockchain.
How the authentication process can works here? Is there a way to scan some product (its ID) and use this blockchain database to make sure its original one? Is that technology useful in that situation?
Yes, the use-case is actually a pretty standard one. There are many such examples in the supply-chain management industry regarding such uses. Everledger for instance, verifies diamond pieces and their origin.
How the authentication process can works here? Is there a way to scan
some product (its ID) and use this blockchain database to make sure
its original one? Is that technology useful in that situation?
I think you should refer to it as product (origin) verification. It is quite simple as long as you abstract out the blockchain technology itself. This is what I mean by abstracting out the blockchain technology- think of a blockchain as an immutable ledger (database) in which data can be inserted once, but then can never be changed or removed from the middle, and you can always read from it.
Just assume there is a blockchain technology (I'll add the details about the blockchain in the end.) Now, by definition, you can always add data to it, in your case some tracking number/ QR/ ID, etc. When you have to verify the product, you have to make sure that the entry exists in the blockchain for the corresponding product. Simple as that. And yes, this is one of the best known use cases of the blockchain, especially in a shared data ecosystem with multiple systems interacting with the same database.
The article that you're referring to is a very simple explanation of a blockchain from a programmer's perspective. Block time, block frequency are all variables that vary for different use cases. I'd suggest you look into already mature blockchain technologies and deploy them, and focus on your use case. You can use Ethereum technology as a local node. You can then use web3.py, a very mature Python library to interact with your blockchain. Or you can simply use distributed ledger, Hyperledger Projects would be an example, or even simpler (and in my opinion, much better) BigchainDB. With all these technolgies, you can store any kind of information you like on the blockchain.
Related
I'm reasonably familiar with maintaining a database schema over time when developing backend applications using migrations. For example, adding a new column means creating a new migration file which will eventually be applied once pushed to production.
However I'm a bit unclear when it comes to one-off data updates. A specific customer might want a minor change to their set of data. Is there a convention in maintaining and recording these specific changes over time?
Your question isn't an exact fit for the SO rules, as it doesn't really have a factual answer; it's quite broad and opinion based, so we might pick up a few down votes..
Personally, I'd manage those sort of things like this:
System has a facility to run SQL directly, locked down
Support team write an SQL to carry out the work, give to customer
customer applies the fix/runs the SQL
any auditing, logging, backup is a task for your system that applies the update. Adopting a similar strategy to migrations would probably be sensible (a table logging what, when and why, so updates aren't repeated)
It could be pretty dangerous to have, as a facility, if it were exposed and free but there are myriad ways to counter that- perhaps you'll make a pub/priv key pair per customer, and encrypt the sql before you give it to the customer, the system will only run sql that decrypts successfully, so while your support team is the only holder of the priv key, only they can write runnable sqls.
I don't think it's sensible or workable to do this in a migrations style workflow, coupled with source control because I can't think of a really good way of keeping the customer specific stuff separate from the core codebase in a way that doesn't become a management nightmare over time
I am considering implementing Robert Martin's Clean Architecture in a project and I am trying to find out how to handle non-trivial use cases.
I am finding it difficult to scale the architecture to complex/composed use cases, especially use cases where the actor is the system as opposed to a user, as in system performing some sort of batch processing.
For illustration purposes, let's assume a use case like "System updates all account balances" implemented in pseudocode like
class UpdateAllAccountBalancesInteraction {
function Execute() {
Get a list of all accounts
For each account
Get a list of all new transactions for account
For each transaction
Perform some specific calculation on the transaction
Update account balance
}
}
In addition, "Get a list of all accounts", "Get a list of all new transactions for account", "Perform some specific calculation on the transaction", "Update account balance" are all valid use cases of their own and each of them is already implemented in its own interaction class.
A few questions arise:
Is the use case "System updates all account balances" even a valid
use case or should it be broken down into smaller use cases (although
from a business prospective it seems to make sense, it is a
legitimate business scenario)?
Is UpdateAllAccountBalancesInteraction
a legitimate interaction?
Is an interaction allowed to/supposed to orchestrate other interactions?
Is code that orchestrates other
interactions really belonging somewhere else?
Is it just OK to have
UpdateAllAccountBalancesInteraction as an interaction, but have it
call functions shared by the other interactors rather than act as an
orchestrator of other interactors?
Clearly, you have a new for high level interactions that share some (or a lot of) common functionality with lower level interactions. This is ok.
If the business requires a use case called UpdateAllAccountBalances, then it is a valid use case, and it's good that you're naming it in a way that reflects the business logic.
It's o.k. for one interaction to call other interactions, if this reflects your business logic accurately. Ask yourself the following question: If the requirements for UpdateAccountBalance change, should this also affect UpdateAllAccountBalances in exactly the same way? If the answer is yes, then the best way to achieve this is to have UpdateAllAccountBalances call UpdateAccountBalance, because otherwise, you'll need to make a change in two places in order to keep them consistent. If the answer is no, then you want to decouple the two interactions, and this can be done by having them call shared functions.
My suggestion is to approach the problem differently. Represent the problem itself in a domain model, rather than using a procedural approach. Your seeing some of the problems with Use Cases, one of which is that their granularity is generally indeterminate.
In a domain model, the standard way to represent a specific thing (i.e. an "account") is with two objects. One representing the specific account, and an associated object representing those things common to all accounts.
AccountCatalog (1) ---- (*) SpecificAccount
In your example, SpecificAccount would have a service (method) "UpdateBalance". AccountCatalog has a service (method) "UpdateAllBalances", which sends a message UpdateBalance to all SpecificAccounts in its collection.
Now anything can send the UpdateAllBalances message. Another object, human interaction, or another system.
I should note, that it can be common for an account to "know" (i.e. maintain) its own balance, rather than it being told to update.
In the spirit of tell don't ask and never let an object get into an invalid state oop design, I'm wondering how persistence would be handled in a dynamic environment.
For a contrived example, imagine you need to write a POS application for an airline. You can only sell seats that are available. Seats are grouped such that plane -> sections -> rows -> seats. If a section is unavailable then all rows and therefore seats in that section are also unavailable. And obviously if a row in unavailable then all seats in the row are also not available.
Now the environment is highly dynamic in that maintenance personnel may be making sections, rows, or seats available/unavailable frequently. Further, imagine it's somewhat expensive to build the airplane object graph. However without constructing the entire graph for each sale attempt I don't see how you can keep business rules out of the persistence layer, which in my mind is an absolute must.
Is oop just not a viable choice for this kind of problem?
Edit:
If it makes a difference, assume the system is persisted by a db server and the inputs to the system are made via http thin clients.
I don't see why you can't construct the airplane object once, and manage it on the fly? You'd have to make it safe for concurrent access, but isn't this EXACTLY the type of problem OOP is good for?
Maybe I misunderstand your scenario.
Separate seat availability from from the plane itself. The whole plane can't be reconstructed on each request, but the seat availability might be able to be requeried each time.
availableSeats = availabilityService.getAvailableSeats(flightId)
availableSections = planeObj.getAvailableSections(seatAvailabilityList)
which form is a correct OO design?
"Matter of taste" is a mediocre's easy way out.
Any good reads on the subject?
I want a conclusive prove one way or the other.
EDIT: I know which answer is correct (wink!). What I really want is to see any arguments in support of the former form (order.fill(warehouse)).
There is no conclusive proof and to a certain extent it is a matter of taste. OO is not science - it is art. It also depends on the domain, overall software structure, etc. and so your small example cannot be extrapolated to any OO problem.
However, here is my take based on your information:
Warehouses store things. They don't fill orders. Orders request things. They don't know which warehouse (or warehouses) the things come from. So a dependency in either direction between the two does not feel right.
In the real world, and the software, something would be a mediator between the two. #themel indicated the same in the comment to your question, though I prefer something less programming pattern sounding. Perhaps something like:
ShippingPlan plan = shippingPlanner.fill(order).from(warehouses).ship();
However, it is a matter of taste :-)
In its simplest form warehouse is an inventory storage place.
But it also would be correct to view a warehouse as a facility comprised of storage space, personal, shipping docks etc. If you assume that view of a warehouse then it would be appropriate to say that a warehouse (as a facility) can be charged with filling out orders, or in expanded form:
a warehouse facility is capable of assembling a shipment according to a given specification (an order)
above is a justification (if not proof) for: warehouse.fill(order); form. Notice that this form substantially equivalent to SingleShot's and themel's suggestions. The trick is to consolidate shippingPlanner (an order fulfillment authority) and a warehouse (a inventory storage space). Simply put in my example warehouse is a composition of an order fulfillment authority and an inventory storage space and in SingleShot's those two are presented separately. It means that if such consolidation is (or becomes) unacceptable (for example due to complexity of the parts), then the warehouse can be decomposed into these two sub components.
I can not come up with a justification for assigning fill operation to an order object.
hello? warehouse? yes, please take this order and fill it. thank you. -- that I can understand.
hey, order! the warehouse is over there. do your thing and get fulfill yourself. -- makes no sense to me.
Let's say I am modelling a process that involves a conversation or exchnage between two actors. For this example, I'll use something easily understandable:-
Supplier creates a price list,
Buyer chooses some items to buy and sends a Purchase Order,
Supplier receives the purchase order and sends the goods.
Supplier sends an invoice
Buyer receives the invoice and makes a payment
Of course each of those steps in itself could be quick complicated. How would you split this up into use cases in your requirements document?
If this process was treated as a single use-case it could fill a book.
Alternatively, making a use case out of each of the above steps would hide some of the essential interaction and flow that should be captured. Would it make sense to have a use case that starts at "Received a purchase order" and finishes at "Send an Invoice" and then another that starts at "Receive an Invoice" and ends at "Makes a Payment"?
Any advice?
The way I usually approach such tasks is by just starting to create UML Use Case and high-level Activity diagrams for the process. Don't bother about specifics, just give it your best shot.
When you will have a draft you would almost immediately see from it how it could be improved. You could then go on refactoring it - getting the use case smaller, structuring large Activities and so on. Alternatively you could lump a couple of Use Cases together if they are too small.
Without knowing the details of your project I would just go ahead and make each step a separate Use Case - they all seem to be self-contained and could be described without any cross-references. If while doing so you will find any dependencies you could always rethink the approach.
Also consider use 'extend' and 'include' blocks for common elements like logging, security etc.
Yes, there are many possibilities here. In your example above it could be even more complicated by the Buyer making multiple partial payments to pay the bill.
You probably need to create complete workflow use cases. Splitting each of the above steps into their own use cases may not prove useful as some of the steps will have pre & post conditions.
I work on the QuickBooks source code and the number of ways that a transaction can flow through the system is daunting. It is almost impossible for our QA guys to test every combination.