Decomposing CRUD to a Task Based UI

[@אבידןטל-נ3ת]

This channel is pure gold, the topics tackles real complex scenarios with simple explanation, thank you for that

[@CodeOpinion]

Glad you like them!

[@heikenem]

Totally agree

[@burjisazrael4164]

Thank god somebody came around and talked about this at last! In a real-world application, creating or changing data has implications and happens as part of a task in a process, not on a whim.

[@JasonMogera]

This is great! I been trying to communicate this methodology to my whole team and this simplified it! Thank you!!!

[@diederikfrombelgium]

Great video! I actually was in a CRUD form situation a few months ago, I can now see that applying task based UI would've been so much easier instead of inferring all the information we received from the form. Thanks for sharing!

[@CodeOpinion]

Thanks for watching!

[@CreativeB34ST]

A big factor is having good communication with the client and understanding what they want. Sometimes they say they want a big edit form, but a lot of times, if you explain the benefits of having task based forms, they would rather be interested in that. It helps a lot when practicing event modeling which is also beneficial to your project management and overall structure of your domain model.

[@CodeOpinion]

Absolutely. Myself and James Hickey spoke with Adam Dymitruk about Event Modeling over on my Loosely Coupled Show. For those interested, check it out: kzbin.info/www/bejne/oJnck4iXZcRlm6s

[@Jason_Shave]

An effective way of determining these commands and events is to host an Event Storming session with the business domain experts. It can be a very fun exercise that exposes the intent of the system, which leads you to create these task-based interactions. Another great video Derek!

[@CodeOpinion]

Thanks! Hopefully I'll get to some videos on Event Storming in the future.

[@thatoneuser8600]

In the book Implementing DDD, it gave an example of the Entity called "Book" where a typical book goes through all it's phases in real life, from rough draft, to editing, to marketing, to publishing, etc. The author said that each of these stages of the Entity's lifecycle should have its own Bounded Context, where in each of these stages, a different model of Book will exist, even if a single Book has the same identity as it goes through each of these Contexts. So my question is: what's a lifecycle stage? I know it's the stages between an object's creation and deletion, but what's the in-between? Are the lifecycle stages the same as the domain events that you would make known in the Event Storming process (each orange sticky-note)?

[@marshal-psiren]

Excellent clear and concise explanation with a working example that really drives the concepts home. Looking forward to seeing the compositional UI video, keep up the great content 👍

[@CodeOpinion]

I will for sure get into compositional UI in the future. The next video going out just briefly touches on it but doesn't really show implementation. I'm more just talkin about HTTP APIs in the context of CQRS and Task Based UI.

[@FernandoZabin]

This video is my favorite! It changed the way I structure the UI and server resources. I was watching it again after a while and it's still great. Thanks!

[@CodeOpinion]

I'll likely create an updated or related version soon

[@FernandoZabin]

@@CodeOpinion That's great! Thanks!

[@edcrypt]

This has a great synergy with the Domain Driven Design principle of making intent explicit in your ubiquitous language. If you model your interfaces (methods, APIs...) with clear business intent, it becomes easier to evolve your modeling of the domain as you explore it together with your stakeholders.

[@osman3404]

BEAUTIFUL and EXACTLY what I had in mind. and added benefit is that Audit trails and security is now possible for certain section of the UI

[@CodeOpinion]

Yes, logging gets a bit more specific now about what action/task was taken.

[@TechWithPat]

Making the implicit explicit! great stuff!

[@coderanger75]

Great video. I am definitely going to try and use this strategy going forward. It’s sometimes easy for me to fall in the trap of just creating a UI to update data when I should be more worried about the “why” is this occurring.

[@CodeOpinion]

Sometimes things really are just CRUD. I usually find these to be things that are on the fringe and not core to the domain. They are usually referential. Not sure if that's a good explanation. I probably need an example :)

[@CodeOpinion]

Having said that, things within the core part of your domain are very likely workflow driven by commands/tasks.

[@Bonmoustache]

Thank you very much for the knowledge you share, just a question on the chosen icon for the Inventory dropdown list in the Task Driven UI at @6:39min. Is there a reason for the icon to be the $ money icon? or is it a copying code slip since inventory tasks are modifying stock units and not $ units?

[@RdozeTV]

Wow now I fully understand the value Thanks

[@ferooref7614]

Do you have any video series where your building and whole application ? Or are u planning on doing something like that using DDD ?

[@CodeOpinion]

I do not. The plan is to create and publish a full course at some point tackling a real domain and building out an application. Sooner rather than later I will do that.

[@reynaldlamury4772]

@@CodeOpinion are you gonna publish the course on youtube or is it paid course? is the task based ui implemented in the course ? Thank you

[@xDedMopdex]

@@CodeOpinion looking forward for this

[@bearforbearBK]

I love the concept but if you are using auto save when do you make the input inactive and request the reason for the change?

[@CodeOpinion]

Not entirely sure you mean? Auto saving meaning you're not forcing the user to do anything? That may make sense in a type of "draft" situation. But after that, you want the users to be explicit about their actions.

[@bearforbearBK]

@@CodeOpinion yes as the user is filling in the fields the inputs are being saved without requiring the user to initiate the save. I guess after the form is closed and reopened, I could make the field inactive and require the reason for change. I like what you are saying so will look to incorporate it into my ui.

[@Utsuhoagie]

Great video, with simple yet realistic examples I'm currently working on my capstone project and the initial diagrams/use cases I had when designing the system looked awfully "CRUDdy", most of them were just "Create/Read/Update/Delete [X entity/entities]" rather than actual tasks a user would expect the system to do, especially on the admin's dashboard side (the other users' side do have a couple more task-like use cases). I'll try to fix some of those, defining more concrete tasks if possible

[@carlosjosejimenezbermudez9255]

This was just what I needed after your last video about not using CRUD based services.

[@CodeOpinion]

Hopefully it helped!

[@raghuveerdendukuri1762]

While I like this idea of TASK UI and it will be a possible thing through eventstorming sessions,I feel, it will be a big change in thought process in terms of defining options in UI when compared to CRUD based UI. Frankly I still think UI in CRUD perspective while trying to use events, this video is an eyeopener that is making me think!!!

[@CodeOpinion]

It's a shift in thinking, that's for sure. However if you talk with users they generally will speak in commands and events when talking about process, from my experience.

[@raghuveerdendukuri1762]

@@CodeOpinion I used to do most by myself over time and while DDD is making me think to go fully in sync with customer's terminology, Task UI perspective keeps me on the toes I suspect, have to try and see how much I can manage, in a green field application that I am handling now. Thanks Derek :)

[@colton2432]

Do you have thoughts on correcting actions? For example, the user incorrectly typed in something on one of their tasks. Let's say they mistype the quantity they are adding to a particular item. For example they type '55' instead of '5'. To correct this they could go in and use the same command but type '-50' however if people are listening specifically to the recount event they may see it as an anomaly.

[@CodeOpinion]

Usually you'll do a full reversal of the 55, then do the 5. This is typical in accounting. Basically you're voiding the other action.

[@AlexeyA-my5sx]

Hi! Great video! You showed how to decompose UI for already saved product. As for me it's easy enough) I have several questions related to initial product creation: 1) How about creating the new product? I mean how to properly handle a big set of initial data to populate the AggregationRoot? Do you use some kind of UI wizards or separated forms for create/edit in you projects? 2) In your example when to create some kind of ids (uuid, ulid, db sequence etc) for passing to each BC for the new product? 3) Do we need to combine "initial create commands" sent from the UI in batches or every command should be atomic? Thanx!

[@CodeOpinion]

Good question. I've had it a couple times so I plan on creating an example around initial creation. 1) One service might own the initial creation, but not every service might care about that happening. Maybe it does, and the client can send each service the relevant call to "create" that in each service 2) The generated ID (could be from the client) is then the same across all services to reference the unique entity. 3) You could do call each service from the client, or pass the initial request and have the first service then have a long running process to do the interactions with the other services.

[@kimstacks]

YOu mention something about another video on composition. Is it up yet? if so, what's that video?

[@CodeOpinion]

Not yet. It's on the list of topics though.

[@dElectroBuddha]

Same question 8 months later, is the video on UI composition out yet ? 😊

[@drakelambert1181]

Would love to see source attached for your samples

[@drakelambert1181]

Also +1 for a live stream

[@CodeOpinion]

All sample code and slides (that I've created) for any of my videos is available to developer level members of my channel. You can get more info: kzbin.info/door/3RKA4vunFAfrfxiJhPEplwjoin

[@CodeOpinion]

Haven't done a live stream in awhile. What specifically were you thinking of? Q&A type thing or on a specific topic?

[@drakelambert1181]

I’m not sure how it would work out in practice, but I've long wanted to be a part of a stream like this: Overall, one or more streams would cover one project from receiving requirements to delivering a product. I'd keep the product super simple and try to make every part of the process collaborative with the audience. Part one might just be about requirements elicitation/validation and decomposing the problem. Further parts could get into simple UI mockup and actual implementation. It might be a good idea to prepare before hand with some boilerplate. To add a life-like flair, I'd through in requirements changes at random points. IMO, the task oriented architecture you've been demonstrating really flexes when responding to change. By isolating the implementation of tasks, they can easily evolve independently.

[@drakelambert1181]

That's a lot of work for one person though, and it's part of the reason you don't see me linking my own stream 😅

[@codewithkashif]

Again amazing content!!

[@CodeOpinion]

Thanks! Appreciate the comment.

[@someguyO2W]

This is excellent

[@mehdi-vl5nn]

As a new programmer, I have a question: Is this task-based UI you mentioned the same as DDD? I'm actually looking for more resources on this.

[@MerrionGT6]

Very good explainer.

[@CodeOpinion]

Glad you think so!

[@stefangabor5985]

I was wondering when you're going to talk about this, CRUD is the old paradigm that no longer works well with the API calls.

[@yurimelo3404]

What's SKU?

[@CodeOpinion]

stock keeping unit

[@nemanjazivkovic6895]

Thanks for another great video!

[@CodeOpinion]

Glad you like them!

[@pascallubbers2286]

Could you maybe explain how you would implement bulk operations in case the client really wants such a feature? Like cancelling multiple orders at once using checkboxes? I know Microsoft often does it by dispatching multiple requests to satisfy the bulk request but that only solves the problem in case you would allow some requests to fail.

[@CodeOpinion]

Have a command that is for bulk operations. You can then process the command and fan them out to individual jobs asynchronously if you're using a queue.

[@pascallubbers2286]

@@CodeOpinion So basically you give up immediate consistency and process the individual commands one by one asynchronously. I guess if there's no need for immediate consistency, this would be a proper solution. You could use some long running process to guard consistency eventually. I would be interested though how you would approach this case when immediate consistency is required. I guess it would greatly impact the aggregate design right?

[@edgeofsanitysevensix]

This is interesting, but I think the UI style might be a bit foreign to a lot of users, especially in my sector. Would be possible to change CRUD actions into Task Events? I suppose you'd need some kind provider that takes in the change, compares it with current state then derive an Event. :/

[@CodeOpinion]

Ya the issue here is if you're using CRUD, then you have to start trying to figure out basted of deltas what the intent was. And at that point you're guessing. You'll likely just end up with CRUD type events. ProductChanged or ProductPriceChanged style events. While those have use in certain context, they lack being explicit about what the actual business case was for the state change.

[@edgeofsanitysevensix]

@@CodeOpinion what is fundamentally wrong with more atomic events rather than broad business ones in this case. To establish an event a fair amount of business analysis needs to be done I think. Also if business practices change we might have a problem? Whereas smaller focused events may fit into new business practices should the requirement arise. I have a hard time trying to establish what a business event actually is as it requires quite significant break down of our practices

[@kralkatorrik34]

I like this approach very much, but sometimes it's just better to keep it simple and go with CRUD. Task-based UI significantly increases the initial development time and may not be suitable for POC/MVP stages of the project, or when you're tight on the budget. In my experience, clients rarely care enough about the UX or tracking user activity to justify this approach's cost/dev time increase. I feel like it is absolutely fantastic when you want to release a product that is available to the general public, but as soon as you move to the niche software or applications that will mostly be used in-house, the client will likely not be interested in this approach. Just for comparison: CRUD: - GET - detail view - POST - create view - PUT - update view - DELETE - delete action 4 in total vs Task Based: - GET - detail view - POST - create view - DELETE - delete action - POST - price increase - POST - price decrease - POST - unavailable - POST - free shipping - POST - cost increase - POST - cost decrease - POST - back-ordered - POST - inventory adjustment - POST - ship product - POST - receive product 13 in total Then let's say that in the best-case scenario you need to write at least 5 unit tests per endpoint(happy path, validation, anonymous user, unauthorized user, non-existing object). It's 65 test cases vs 20. Not even talking about the service layer under it that also needs testing. On top of that, you need modal forms for each action, context menus, and so on. It's ridiculous how much more time it takes to go through planning, design, development and QA. That's a LOT of extra work and I think it would be worth mentioning the downsides of the Task/Activity/Command-based approach, without doing that it may give people the wrong impression that this should be the "default" approach because it is so much better than CRUD, while it comes with a huge cost.

[@CodeOpinion]

Thanks for the reply. By itself, I'd agree that a task-based UI can be too much work. Where it fits best is when you want to capture business intent, most often because you want derive events from it. Eg, Event-Driven Architecture. Publishing events that you can consume to extend the functionality of your system.

[@richardhaughton9633]

HI Derek, First of all, thanks for all your great videos. Is this UI Blazor? Razor/MVC? or anything else? Thanks!

[@CodeOpinion]

Nope, just static HTML. Just wanted to whip something up quick to illustrate.

[@digitalox4162]

Excellent.

[@LawZist]

Nice!

[@pc1234asdf]

Yes exactly. I abandoned crud with arbitrary commands available directly at my routers. People give other people commands, and so do my servers. CRUD is nothing more than a crude abstraction above usual ORM activity.

[@CodeOpinion]

The way I like to think of it is moving workflow and process to code rather than in peoples head. Often times when software focuses on giving the user CRUD, all the workflow is done by the user. They must know the workflow steps and how to enter X before Y. Task driven is about guiding the user down so they don't need to know the workflow.

[@rorycawley]

@@CodeOpinion that's a perfect explanation

[@rainron2664]

👏👍