\n\nTry not. Do. Or do not. There is no try!
\n
I’m calling this the Yoda Principle.
\nMaster Yoda said that to Luke Skywalker a long time ago in a galaxy far, far away. He was teaching Luke how to name commands properly while trying to untangle some legacy enterprise mess.
\nI’m sure you’ve also seen a death star of weirdly-named stuff. Some of them have already tripped you hours of thinking whether someone named this thing badly, or there’s some hidden truth behind it.
\nLet’s discuss that by the example: E-Commerce order fulfilment.
\nThe order is placed automatically once the customer confirms the items in the shopping cart. We’re not making any product reservations before the shopping cart is confirmed, as this would lock it for other customers, and, as you know, they tend to drop items from their carts.
\nOnce we receive the event notification that the cart has been confirmed, we’ll start the order fulfilment process. It starts (as mentioned) with the order initiation, which acknowledges and initiates the multi-step fulfilment process.
\nThe first step is checking product availability before confirming the order. We need to determine whether we can proceed with completing the shipment and initiating product payment. If the product is unavailable, we need to either ask the customer to wait until we have it again or cancel the order.
\nWe have dedicated modules for order fulfilment and for inventory. Fulfilment is the orchestrator, and inventory is responsible for tracking the state in warehouses.
\nThe ordering module would need to call the inventory module to verify product availability. We could send a command (through the messaging system or web api). How would we name it?
\nWhat about VerifyProductExists? We’d send the product id and quantity from the order information, and return true if we have enough products, false otherwise. Sounds fair, right?
\nWell, it may seem nice at first glance, but what happens if more than one order verifies the same product availability, and we’re running short?
\nThen we’re vulnerable to race conditions I described in Tell, don’t ask! Or, how to keep an eye on boiling milk. The information we get is only valid at the time of querying. If we don’t lock the product quantity, it can change before we get a response (think: Black Friday-like demand).
\nNaming our command like VerifyProductExists is a mistake.
\nVerifyProductExists is not even a command; it’s a query. Command is a request (intention) to run business logic. Query is a request to return data.
\nOf course, pragmatically, our command can return status information about the result of our operation. But the intention is different.
\nWhat’s our real intention here?
\nThe real intention is that we’d like to reserve products so we can ship them and get payment for them, not to verify if they exist. It’d be better to name our command as ReserveProducts or LockProducts.
\nWhy does it matter?
\nIf we’re naming our commands with Verify/Validate/Check prefixes, we’re putting ourselves into the wrong mindset. We’re not focused on actions and integrations, but just brief checking. If we’re in such a mode, it’s easy to handwave the integration complexity.
\nLocking for shipment may require sending someone to double-check that the product is in the warehouse and hasn’t been stolen, damaged, or other steps. It may be an async process on its own. Still from the ordering module, we should not care, as we’re telling what our intention is and expect to get events informing us whether the reservation succeeded, failed, or timed out (we don’t want to lock products forever in case of order fulfilment issues, but only for some time).
\nPrefixes like Verify/Validate/Check, etc., are just synonyms for trying. And well, commands are always a form of trying. The handling module can reject the command, as its business rules and state are the source of truth.
\nWe should always assume that the command processing can fail. We should not be discouraged by that, and we should double-check everything. We should not be intimidated by the potential failure, but prepared for it.
\nWe should try not. Do or do not. There is no try.
\nWhat if we have both? So VerifyProductExists and LockProducts? It can work if the first one is a query used by the Shopping Cart module, without any guarantee that the data isn’t stale, on a best-effort basis.
\nIf we’re always requiring VerifyProductExists from the handling module before LockProducts, we’re making our communication chatty. I described that in What does Mr Bean opening the car have to do with programming? that this is not only a bad developer experience, but also just redundancy. Locking should already verify whether the product exists, so why require someone to memorise those scenarios instead of checking it internally?
\nThe same goes for cases like:
\nAll of them either hide a missing business concept or should be a business rule verified within the specific action (e.g., confirming an order).
\nI recognise this may seem nitpicky, but big things are built on small details.
\nIf we don’t think about such things, we’ll not only end up with misnamed integrations but also fight race conditions and incorrect boundaries.
\nThen we’ll be doomed.
\nSo better think twice and do or do not.
\nMay the force be with you!
\nOskar
\np.s. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.
","excerpt":"Try not. Do. Or do not. There is no try! I’m calling this the Yoda Principle. Master Yoda said that to Luke Skywalker a long time ago in a…","fields":{"slug":"/yoda_principle_in_command_design/","prefix":"2026-04-20","langKey":"pl"},"frontmatter":{"title":"Yoda Principle for better integrations","author":"oskar dudycz","category":"Event Sourcing","disqusId":null,"useDefaultLangCanonical":true,"cover":{"childImageSharp":{"resize":{"src":"/static/b559c6d70cdf5430d251306c8b61d60b/2a4de/2026-04-20-cover.png"}}}}},"authornote":{"id":"f1fb8a26-256d-5b24-9b06-ad19a0c2961b","html":"Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.
\nSome time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.
\nMany people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.
\nMany seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?
\nThe end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.
\nI believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.
\nAfter I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?
\nPeople usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).
\nThe truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.
\nTherefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.
\nPolish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.
\nCheers!
\nOskar
"},"site":{"siteMetadata":{"facebook":{"appId":""}}}},"pageContext":{"slug":"/yoda_principle_in_command_design/","lang":"pl","langKey":"pl","prev":{"id":"b926df88-a08c-5390-a100-75bcdf3bcffe","fields":{"slug":"/passive_aggressive_events/","prefix":"2026-04-13","source":"posts","langKey":"pl"},"frontmatter":{"title":"Anti-patterns in event modelling - Passive-Aggressive Events","category":"Software Architecture"}},"source":"posts"}}, "staticQueryHashes": ["2742854296"]}