So powerful tool! i am happy because he generate a code in an architecture like mine in my projects

This is how code should be engineered!

@Euquila

Жыл бұрын

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

@GeorgeIsGary

Жыл бұрын

@@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.

@tcortega

Жыл бұрын

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.

Such a powerful tool!

Love the background!

Well explained and great tool. Well done!

@IntentArchitect

Жыл бұрын

Glad you liked it!

Excellent tool👍

Very nice tool. Can you share this project? That way we can check at code level the result of the tool use.

@IntentArchitect

Жыл бұрын

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 :)

Super

So much knowledge, that brain is going to collapse 😂

@IntentArchitect

Жыл бұрын

😂😂😂

Nice tool, thank you for your efforts. I disaggre with some points: 1- Commands should not be a request body. In a single API world maybe it is ok. In a monorepo world, that is not applicable. 2- Authorization concerns and model bindings should be sepereated from commands and should be in API layer. 3- UnitOfWork should be outside of Repository. We command DB Context to save changes for the entire changes, not a single entity. 4- I don't understand why we call SaveChanges in CreateCustomerCommandHandler, UnitOfWorkBehaviour doesn't handle it? 5- UpdateCustomerHandler automatically sends its event. It is very hard to read by developers. Maybe we could use some DDD concepts and leave EventPublishingBehaviour for just dispatching.

@IntentArchitect

Жыл бұрын

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.

Would be interesting, a clean architecture without third-party components!

Is this available for something like a free trial for developers ?

@IntentArchitect

Жыл бұрын

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.

Does this do anything more sophisticated than CRUD / REST and does it produce code for the UI?

@IntentArchitect

Жыл бұрын

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.)

Great video. I had a question regarding the customer class at 1:08 why are there public setters? Isn't this a huge risk to violate immutability? I know there are ways to maliciously violate immutability but from a risk perspective isn't this allowing a developer to change a classes state by mistake? Another way of posing this questions would be ..why isn't there a constructor that takes in the arguments and only has public getters?

@IntentArchitect

Жыл бұрын

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.

Don't use automapper for anything. Use constructors.

@BrettRobb007

Жыл бұрын

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

What is the pricing?

@IntentArchitect

Жыл бұрын

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.

This video made me very sad, knowing that I won't be able to use this tool.

@IntentArchitect

Жыл бұрын

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.

ah again... This is not clean architecture. This is another copypaste from ms that has nothing to do with CA. In CA application and enterprise business rules are part of domain layer. In CA usecases are not application layer from n-tier. In CA all infrastructural details does not matter because they can change and main idea is to abstract them from your domain, because your domain is non functional without usecases. Your auth provider, mappers, commands etc they have nothing to do with how business is functioning. That's the whole point of clean architecture.

@IntentArchitect

Жыл бұрын

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.

@Metalyga

Жыл бұрын

@@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.