eShopOnWeb Architecture (16/16) - uses clean architecture

eShopOnWeb Architecture (16/16) - uses clean architecture

On a high level eShopOnWeb uses clean architecture.

The main idea of clean architecture is that the solution is spilt into different projects (or layers) and that the?domain project is at the centre?with all other projects pointing into it. Other projects typically include an Infrastructure and UI project. Importantly these point into the domain project via?interfaces?not?concrete dependencies.

Concrete dependencies on things like Entity Framework and Redis are defined in the Infrastructure project.?Dependency injection is a fundamental concept?in clean architecture and is used to inject these dependencies at?runtime.

The diagram below (taken from the?accompanying eBook?for eShopOnWeb) shows a typical clean architecture setup…

No alt text provided for this image

The main proposed benefits of clean architecture is that because its?heavily abstracted?its easy to?swap out implementations?and also?easy to test. I’ve definitely seen these benefits when I’ve used it BUT unfortunately these benefits come with huge cost in terms of extra complexity of the overall solution.

One thing in particular with clean architecture is that it’s so abstracted there’s?extra cognitive work?required to actually know where in the application something is actually done and how things ‘fit together’.

As clean architecture separates code by technical not functional concern it can often have really low functional cohesion and so code for?any one use case is scattered all over the place. For example below shows the files (note.. some of these are needed by alternative architectures too) involved in the?Get My Orders?use case in eShopOnWeb. To get an end to end understanding of how this use case actually works I have to?navigate through a lot of files and projects.

No alt text provided for this image

I?find this kind of solution architecture?very unsatisfying?to work with as a developer and definitely notice myself using ‘Go to Implementation’ a lot when reviewing systems which use it.

Of course?having so much separation of concerns?also means debugging can be harder, onboarding can be harder, PRs can be larger as often a lot of files to change, tracking bugs back to check-ins can be harder, documenting the system can be harder and yes actually?adding or changing features can IMHO also be much harder.


Vertical slice architecture as an alternative to clean architecture?

IMHO vertical slice architecture is a much more pragmatic and developer friendly macro-architecture.

With VSA we aim to?limit abstractions?and have?high feature cohesion?by placing concrete code which corresponds to any one feature or use case together. For example… in the below still from Derek Comartins?Restructuring to a Vertical Slice Architecture video?on YouTube he has restructured the eShopOnWeb code for the?Get My Orders?use case shown above so that it is all together…

No alt text provided for this image

And the code for Derek's refactor is available on the accompanying blog post on his site.

It might not be one for the 'purists' among us but IMHO having all (or most) of the code for a particular use case together (doesn't necessarily have to be in the same file) is much easier to work with than having to?constantly navigate?around layers of abstractions and multiple projects as is often the case with clean architecture.

Of course the above is just my opinion and using clean architecture is definitely not ‘wrong’… it’s extremely popular online and because context is everything some projects will absolutely?benefit from the rigid structure it provides. In particular many architects feel it helps less senior developers into the ‘pit of success‘ which basically means its an architecture which makes it harder for them to do the wrong things due to how structured and prescriptive it is.

What do you like to use in your apps? Clean architecture, vertical slice architecture or something else?

Completely agree. The “separation of concerns” architecture on large projects quickly becomes unwieldy. If not for the ability to use navigations tools, it’d be almost unmanageable. It feels like Microsoft came to this conclusion too with MVC when then came out with razor pages. If you’re app or primarily page focused, then why force something MVC on it?

回复
Ian Hockett

Software Engineer | Software Architect | Passionate about Improving Patient Outcomes | Currently @ Exact Sciences

3 年

I prefer clean architecture or hexagonal architecture over VSA for finer grained services the end up spanning many features. Being able to find a feature based on project / folder structure is key for that. One challenge, though, is keeping track of code duplication or over-eager attempts to build common libraries.

回复
Aleksa Kuzman

.Net Developer and computer graphics aficionado

3 年

Hmm I don't know how this fits into this discussion but I find clean architecture much more managable when it is used on smaller services. So high level microservices with project level clean architecture is not a bad fit IMO. Haven't really given a vertical slice architecture a shot yet but it seems to me like it is an attempt to solve an inherent complexity that monoliths present. I would rather split a project into multiple services when it becomes unmanagable than try to solve a problem with different architecture style in one huge project.

回复
Oshadhajeewa Thrimanna Vithanage

Software Architect / Azure Solution Architect / DevOps Engineer

3 年

Dave Callan what do you prefer? Clean architecture or Vertical Slice Architecture

Dave Callan

Follow for daily .NET posts | Microsoft MVP | Senior Software Engineer

3 年

Part 1 - uses marker interfaces to communicate intent and enforce design constraints https://lnkd.in/d-PWGS3J Part 2 - uses Value Objects to model domain concepts without identity https://lnkd.in/dX_eFuti Part 3 - uses custom exceptions to more explicitly express what has gone wrong https://lnkd.in/dHpp2-E3 Part 4 - uses the MediatR library to keep controllers thin https://lnkd.in/dX7VfD6i Part 5 - makes regular use of Guard Clauses https://lnkd.in/d--hmXz5 Part 6 - uses private setters and non default constructors to support encapsulation which helps keep the model valid https://lnkd.in/dEwY_iep Part 7 - encapsulates navigation collections so consumers can’t edit them directly https://lnkd.in/dk5DXRKh Part 8 - uses in memory caching to avoid sending unnecessary queries to the DB https://lnkd.in/dg_Y5qUx Part 9 - uses the Aggregate root pattern to ensure child objects are not manipulated out of context https://lnkd.in/d46XBjeC Part 10 - has unit tests which test very low level implementation details https://lnkd.in/dd69BEpU Part 11 - uses AutoMapper https://lnkd.in/deeCwcBa Part 12 - uses the repository and specification pattern https://lnkd.in/dd6RiDUy Part 13 - has some single implementation interfaces https://lnkd.in/drkhgk8T Part 14 - uses parameterized tests https://lnkd.in/dgqTTP4F Part 15 - has a really nice example of the Interface Segregation Principle https://lnkd.in/dgkn5fqx Part 16 - uses clean architecture https://lnkd.in/d-bS24cY

要查看或添加评论,请登录

Dave Callan的更多文章

社区洞察

其他会员也浏览了