วีดีโอ

Hi @kvelez, are you referring to Visual Studio Code? Or possibly Intent Architect?

Hi @kvelez, the Intent Architect patterns are constantly evolving and support .NET9 is already in place (these patterns are also open source on github.com). We are considering doing an updated webinar with on the Clean Architecture with .NET9 and the latest patterns at some stage. Is this something you would be interested in?

Hi @HatsuneM_ALC, thanks for reaching out. We do cover the Clean Architecture as part of our standard Intent Architect training. If you're interested in this, feel free to reach out to our team at info@intentarchitect.com. They will be happy to answer any questions you have.

Hi Luke, thanks for the great feedback and for reaching out! Our team will get back to you asap. Wishing you all the best in New Zealand! 🙌

💯

Hi @shabanelmogy7912, we would be happy to do a webinar which covers this topic. Are there any specific elements of building big applications with Blazor would you want us to cover?

@@IntentArchitect Pos System

@@IntentArchitect Pos system

Thank you!

Hi @qendrimimeri8561, thanks for you comment. We've updated the description with a link to our webinar repository. You can also access it here: github.com/IntentArchitect/Intent.Webinars

@@IntentArchitect thank you ❤

Hi there, Intent Architect is available to development teams. If you're interested in trialing it, head over to our website (intentarchitect.com) to start this process.

Glad you enjoyed it!

Hi @Imploser, thanks for your comment. Let me see if I can offer some additional context: 1. I'm not sure if I fully understand the concern here. Perhaps you could elaborate? As a note, commands do not have to be a request body. However, if you wish to trigger a command from a RESTful HTTP endpoint then accepting the properties of the command from the requests body is typically acceptable. One could introduce an extra contract with mapping to separate the API and Command contracts, but this is usually excessive for most projects. 2. Agree that these concerns should be separated, and they conceptually they are. The one advantage of addressing security logic through the mediator is that it ensures that it is described once and is always enforced even if the request did not come from the API (e.g. if it came from an Integration Event). 3. Access to the UnitOfWork via the Repositories in this pattern is purely for convenience, so that the developer doesn't need to inject in a separate UnitOfWork service every time they need access to it. A different pattern could be applied here based on preference. 4. We need to call SaveChanges in the creation handlers because we intend to return the entity's Id and since the surrogate keys of the entities are Guids they therefore need to be sequential to prevent clustered index fragmentation in the Relational Database. To make sure they are sequential you either need to delegate their creation to the DB (the approach taken here, hence the need to SaveChanges) or to use an in-memory algorithm to create them. Either way is acceptable. 5. Also not sure what the concern is on this point. The developer explicitly specifies that they intent to publish the event in the UpdateCustomerHandler, in code (this is business logic and for the developer to manage). The delayed execution of the actual dispatch to the bus is necessary for transactional reasons (e.g. outbox patterns, etc.). That said, using DDD patterns is a great way to ensure robustness in the dispatching of Integration Events. We recently did a webinar exactly on this (Domain Modeling in Depth with .NET) - please check it out and let us know what you think.

Hi Ucretsiz, please head over to our website (intentarchitect.com) and apply for a trial. Our team will be able to give you pricing for your requirements.

Hi Trong, thank you for your comment. I'm not sure if I'm fully understanding exactly what you're suggesting. Would you mind elaborating? I think viewers would find it valuable. To try give some initial input in the meantime: I think it may be worth noting that the repository interfaces in this architecture are available in the Domain Layer, which means one could pass in the repository service to an operation on an Entity. In this case we would have one Aggregate mutating the state of another. This may be fine in some cases but typically isn't ideal, especially when this pattern propagates throughout the domain and can create far reaching dependencies as all repositories need to be provided for all affected aggregates at the entry point operation. A better alternative would be to create a Domain Service which would encapsulate the business logic of retrieving and mutating the other aggregate(s) in the process, and instead inject this into the operation. This would limit the dependency graph. One could also use Domain Events (as we did in the webinar) to propagate changes between aggregates (side effects) without introducing dependencies to the entry point operation - this is what the Domain Event pattern excels at. These two approaches could be combined so that all business logic remains in the domain, while we simultaneously maintain low-coupling throughout the domain.

Glad you liked it!

Glad you found the session valuable!

Great question, what you are referring to are DDD / Rich Domain principles. These principles can be applied to Clean Architecture, but it is not a requirement of Clean Architecture. Intent Architect does support DDD / Rich Domain Modeling, in-fact we cover this is a fair amount of detail in our “A Deep Dive into Domain Modelling” webinar. I think you will find it talks to all your points here, including locking down property setters by default. Check it out and let us know what you think.

Hi Mark, thanks for your question. The short answer is: Yes, 100%. The longer answer is: Intent Architect is able to automate any pattern that is predictable and repetitive in the software development space. This is done through different Modules. For example, this webinar uses a particular set of .NET Modules to automate a Clean Architecture using MediatR, EF, Repositories, etc. Other Modules could be installed to automate other patterns. Our team (with our community) have created over 100+ modules already, with more coming. It may also be worth mentioning that developers can create their own Modules easily through our Module Builder system - we'll be doing a future webinar on this. We're also planning future webinars to cover automating UI and many other sophisticated patterns / architectures (e.g. DDD, Event Sourcing, IaC, Serverless, etc.)

😂😂😂

Hi Marcos, thanks for your question. We unfortunately didn't keep this particular solution, but we are in the process of publishing a sample "eShop" solution which covers all of the topics we talk about in this webinar, and a lot more. I will post a link to it here as soon as it's ready :)

Hi Ed, thanks for the question. We do offer a trial for teams and individual developers. You're welcome to head over to our website (intentarchitect.com) to initiate this process.

Immutable constructors using factories, removes so many bugs and hidden auto mapper gems 😂

Hi @Metalyga, thank you for your comment. You raise some good points. By applying DDD principles to this architecture, one can ensure that the Enterprise Business Rules are confined in the Domain (Entities) layer. We are planning a full webinar on this approach in the near future. The Dependency Rule is the most important principle of the Clean Architecture and, as you pointed out, some non-functional concerns (e.g. auth, logging, unit of work, etc) have been placed in the Application project. However, the Request Handlers (i.e. Use-cases) have no dependency on these, and could therefore be moved to a separate project (e.g. UseCases.csproj) without needing to change any Application Business Rules. We've opted not to do this by default so as not to over bloat the project layout. The Dependency Rule is nevertheless still applied appropriately in this regard. Since we'd very much like to encourage healthy debate around topics like this, would you mind sharing some links for other viewers to consider? Also, if you'd like to share further input with us, that would be appreciated. You're welcome to email me at gareth@intentarchitect.com.

@@IntentArchitect Why dependency rule is important? For what purpose? For not vendor locking your enterprise and application business rules and to be independent of certain technology, framework or package. To be Independent of any external agency. To be clean. CQRS, MediatR, Field attributes are leaking into application logic, into domain. In clean architecture it violates the idea of use cases. As uncle Bob says: "We also do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks. This layer is isolated from such concerns". So main idea that you have domain packages separated by domain with va, entities, aggregates, ag roots and use cases with interfaces for repositories and for each use cases. Your solution is ms powerhouse. It is working, it is stable, it is good. But it is leaning more toward classical n-tier architecture with new toys than toward clean architecture.

... if your requirement is to strongly express some core business logic. There are no silver bullets in programming when you factor in cost

@@Euquila Yes, of course, not for all kinds of code. It does seem the tool makes cost much less of a factor when you're wanting to go Clean Architecture.

This is actually a completely overengineer of an approach. The clean architecture is useless, and so is every fucking thing he shows in this video.