Відео

if you're only ever building features for one app on one domain, you don't need to worry about this stuff. a domain of entities is something reusable across multiple applications. and a application solving use cases can be presented with multiple UIs.. in theory, it can even access multiple domains. the point of making the separations is to allow them to not be 1:1 to each other at those boundaries. the problem with "features" is that often they involve integrating several apps, and potentially several domains, so "vertical slicing" is already going to happen to get that feature into multiple places, and that's where it gets lost.

F# mentioned nice. That code looks like an affair baby of C# and F# though :D Could be cleaner with more F# idiomatic code for example pattern matching like this: let main args = match args with | [|_; "install"|] -> install() | [|_; workspace|] -> workspace |> collect |> openBrowser | _ -> Console.Error.WriteLine("Specify 'install' to install required tools") Console.Error.WriteLine("OR a workspace to create a coverage report") exit 1 main fsi.CommandLineArgs

Nice work!

I agree that the validator idea is clever, but it’s something many developers would skip over and not even notice. I’d personally go with the custom constructor.

Great video! I'll give it a try, it seems very useful.

is not micro frontend dude, go learn before you bullshiting online

This is gold, I really love that first example with the factory method

As per common practice, these decisions are made at start, or somewhere in the middle. For both cases an approach and design is created and implemented by the developers

Using s like this has dreadful implications for your users if the individual features are more than just a single page. No deeplinking, or bookmarkability for example. Not to mention the weird behaviours of the top window's history stack when frames are on the page (see ua-cam.com/video/W6lvQvdeF8U/v-deo.html ).

I‘ve been doing microfrontends with the Single SPA library. This library follows a router based approach and utilizes SystemJS for loading the individual components. You‘re also able to render apps or parts of apps inside another app.

Result types are just preparing you to eventually distinguish between HTTP status codes for whenever your application gains a web API. You might as well start with them and avoid exceptions altogether. Also, every time you think you could use null as a value, just stop. You're probably wrong. If it's a stand-in for an empty string or zero, just use those values to begin with. You can avoid a lot of null checks that way. Unexpected nulls are always exceptional. The only exception is when you have to interface with someone else's code that doesn't follow this rule, forcing you to handle null like a definite value.

How does the Repository class/module looks like? This have a dependency to the database or the api but they're in the outer layer what violates the rule, but it feels strange to use an interface for this because the repository has to be written in a specific way that the database can understand. Or does it mean it is in the adapter layer it can have direct dependencies to the outer layer?

Actually always you see module federation in real case scenarios

and microfrontends are two different things. Micro-frontends are an architectural pattern and is focused on using modular concepts/techniques. Embedding a website in the application is not how micro-frontends work.

There’s another way as well using module federation

Another approach would be a plugin approach; creating abstractions in the shell front end application - that micro frontends would need to implement. The application shell provides a means for loading the plugin packages (e.g from a config file) and the plugins then load up and participate in the application. For example they could register a menu item, or register a custom component to be rendered somewhere or extend the application shell in agreed ways etc. This requires a great deal more design and thought and you have to deal with compatibility I.e not introducing breaking changes for existing plugins etc. Where it becomes interesting for me is, if you could for example use wasm components, then technically this plugins could still be written in many different languages and compiled to wasm, meaning that similar to microservices you maintain language independence - though that might not be a priority. Down this path basically leads to the idea of distributing an SDK for your application, where developers can develop plugins for it against the agreed abstractions.

I liked the video. Clear structure and on point so I know what people mean when they talk about micro frontends but still don't get the point. Sounds like more pain that it is worth, now you have multiple frontend projects that you have to consolidate together. Worst case scenario you have multiple teams choosing whatever is frontend flavor of the month and you have to maintain that nightmare. Also coordinating styles sounds like a massive overhead. I'd rather have a modular monolith that I deploy as a single unit with one source of truth for styles and other global things like authentication. I have no idea how auth is supposed to work there. Does every frontend project implement it again or do I need to share state with all the frontends now?

nice video!

Nice video and great explanation of one of the most important concept in programming. I have also created a video explaining the SOLID principle with code. Please leave your feedback after watching: ua-cam.com/video/7tDysPSC96o/v-deo.html

In flutter use getit for service locator

Thanks for the very good explaining

Are there any tools available that calculate these metrics and help you visualizing them?

I clean my code with dawn dish soap.

What did I just watch? Could you explain these things with some concrete examples and not just on an abstract university course level?

Really great video!!

Does it support AOT?

Good explanation, keep it up and don't stop posting videos and shorts ❤

Thank you so much for this wonderful video, so informative!

In this specific scenario I believe you should consider using visitor pattern instead of allowing the graph to draw itself

welcome back

very cool