15:53 dependency inversion principle (DIP) 16:11 left-side: database driven design 16:17 Service has dependency on the persistence layer 16:55 right-side: Entity is moved up into the domain layer 17:09 Repository interface 17:18 the persistence layer simply implement the repository interface 17:38 meaning: we can choose the direction of any code dependency
Single Responsibility Principle Lemma 🙂 If a class fails in production there can be only 1 supervisor with a reason to fire you - say accounting. A class no longer conforms to the SRP if there are 2 or more - say accounting and legal.
If your layered architecture is database driven design, you are doing it wrong! I ALWAYS start with the user interface, derive APIs for each use case (screens, user interactions) and think about how to store the data most efficiently last. How on Earth can you define an optimal database design if you don't yet know exactly how the client behaves (what APIs will be called, which order & frequency)?
How is a set of concentric circles semantically different form top-down set of boxes :)? Both express ordering. Arrows can be drawn in both. You just can put more words to the outer ring.
I think there is a slight detail there what was missing from the slides. The direction of dependency is not the traditional way. Instead Everything external depends(gets generalized) inwards. blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
I still don't get how that works. Usually without Lombok you need to add the @Autowired annotation to the constructor to tell Spring to inject those fields but in this setup there is no @Autowired anywhere and Lombok is certainly agnostic of Spring so I can't think of it bringing it with it.
@@GameOfLife55 You don't need to add @Autowired annotation, and in fact you *should not* use @Autowired annotation. Look up spring field injection versus constructor injection.
Great presentation... good slides and concise explanations. I'm a spring newb and this definitely helped me to understand how to implement clean architecture with spring.
interesting...but i'm not sold. in my experience, the costs of building so many barriers to enforce isolation is far more expensive than changing things later on. that is, rarely (if ever) do backends change so much as to ripple throughout, but it takes lots of time to do all that mapping and duplication.
I guess the hexagon architecture is quite expensive to be built in the beginning for sure. However, I feel that this architecture would help a lot as the project is more and more complex, and more new guys are joining the project. If the project would stay small and complexity is manageable, I believe this approach is a kind of overkill.
@@ebichu8126 Now here's the kicker: how can you guarantee that a project would remain small with manageable complexity? If I had gotten a penny for everytime I've heard "Oh, but that'll just be a CRUD application", only to see them struggle 2 years later when the customer expands the scope... Clean architecture really doesn't add that much overhead compared to the net gains you get in the future. You're essentially paying it forward.
@@lievendoclo7478 Yeap, it depends on a contract with your client. if you don't need to maintain the product after building the app based on the contract, you don't need to bother to add fancy architecture in the app. However, if you have to maintain the app in the long run, it would be better to have clean architecture.
@@ebichu8126 In my opinion, software should be written as if you would have to support it. Or as some once said, as if you were writing for a psychopath who knows where you live. Customers tend to change their mind about that too, and then then you’re stuck with all the shortcuts you’ve made. Clean architecture adds *maybe* a couple percents of overhead when it comes to lines of code, but the ROI is incredible. It’s a false flag to say that the other way is cheaper, because it’s not. Not at the end. We need to stop justifying writing bad code.
My idea is that the use case should talk to domain service instead of talking directly to port. Each domain service will handle the business logic for each domain and it is the one that communicates with ports
I think that ports usage is overengineering, and creating interface for each usecase too. Only worth idea is to split services into use cases, crud operations should be considered as one use case
It's not though, because when your app becomes more complex, u may want to separate commands (write operations) and queries (read operations), where commands would be executed via ORM and queries would be native SQL queries using an other technology or even an other database (aggregated read model).
I thought Java Spring Boot already had a small footprint for building applications. Was curious to see how the typical layers of controller, service, repository, persistence or JPA model would go. I've recently seen a .NET Core structure which has a domain, infrastructure and application tier. Have to say I'm not totally clear on business logic in the domain whilst micro-services are built in the application tier. My issues were that I had to know what the business requirement was and where we addressed it. How would I know how to implement it and send back a success or failure response in the form of a message.
This is a great presentation. The only thing that is very debatable is putting the spring Service annotation in the use case service. And also the JsonCreator. As he said, it is his interpretation of the architecture.
It is not debatable, you can create your own annotation to suit your need, it is understandable. But I don't really get the benefit of this structure with legacy MCV pattern, unless we need create more and more adapter to assume that our repository is not tied to JPA
@@xutiTrinh The benefit is that you abstract away the choice of technology from the business logic. So if you were to choose another repository implementation you can just add it with respect to the adapter contract. I don't agree with him having every persistence operation in its own adapter, just create one contract interface for all of them. That said, you have a point. In most cases, this pattern is extremely over engineering and brings with it a lot of overhead code related to mapping and redundancy. Especially if you use a Microservice architecture where you keep the Microservice's size relative small in terms of functionality then just go for the ol' good MVC.
Hi should I use one usecase interface per one "service" (usecase implementation), or can I use a lot of interfaces with one implementation? because I have one service with a lot of usecases and I think it isn't a good approach
To be honest, that's a detail, but I like the fact that I can just see from the folder structure what my use cases are. If you look at SOLID principles, interface segregation supports the idea of having a SAM interface for use cases.
Yeah his coding examples were not great because they mixed too many unnecessary artefacts. He should've ripped out his "SelfValidating" interface, all his custom Spring annotations, etc and just focused on the Hexagonal components. It also got too distracting with the random pitches for the Spring framework.
In this case, deal with your customer j/k. With many use cases combine then IMO it does not solve the complexity of structure, the purpose of hexagon is for developing isolation function at first but it is rare. You gonna mess (or mix) ton of such use case soon
Very interesting topics...but please....a bit more of emphasis man!! Knowledge is a responsability....you cannot do a talk this important with so less energy. :/
15:53 dependency inversion principle (DIP)
16:11 left-side: database driven design
16:17 Service has dependency on the persistence layer
16:55 right-side: Entity is moved up into the domain layer
17:09 Repository interface
17:18 the persistence layer simply implement the repository interface
17:38 meaning: we can choose the direction of any code dependency
Single Responsibility Principle Lemma 🙂
If a class fails in production there can be only 1 supervisor with a reason to fire you - say accounting. A class no longer conforms to the SRP if there are 2 or more - say accounting and legal.
If your layered architecture is database driven design, you are doing it wrong!
I ALWAYS start with the user interface, derive APIs for each use case (screens, user interactions) and think about how to store the data most efficiently last.
How on Earth can you define an optimal database design if you don't yet know exactly how the client behaves (what APIs will be called, which order & frequency)?
How is a set of concentric circles semantically different form top-down set of boxes :)? Both express ordering. Arrows can be drawn in both. You just can put more words to the outer ring.
I think there is a slight detail there what was missing from the slides. The direction of dependency is not the traditional way. Instead Everything external depends(gets generalized) inwards. blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
The trick with using lombok to generate the constructor combined with the @Service annotation is awesome!
I still don't get how that works. Usually without Lombok you need to add the @Autowired annotation to the constructor to tell Spring to inject those fields but in this setup there is no @Autowired anywhere and Lombok is certainly agnostic of Spring so I can't think of it bringing it with it.
@@GameOfLife55 You don't need to add @Autowired annotation, and in fact you *should not* use @Autowired annotation. Look up spring field injection versus constructor injection.
Great presentation... good slides and concise explanations. I'm a spring newb and this definitely helped me to understand how to implement clean architecture with spring.
interesting...but i'm not sold. in my experience, the costs of building so many barriers to enforce isolation is far more expensive than changing things later on. that is, rarely (if ever) do backends change so much as to ripple throughout, but it takes lots of time to do all that mapping and duplication.
I guess the hexagon architecture is quite expensive to be built in the beginning for sure. However, I feel that this architecture would help a lot as the project is more and more complex, and more new guys are joining the project.
If the project would stay small and complexity is manageable, I believe this approach is a kind of overkill.
@@ebichu8126 Now here's the kicker: how can you guarantee that a project would remain small with manageable complexity? If I had gotten a penny for everytime I've heard "Oh, but that'll just be a CRUD application", only to see them struggle 2 years later when the customer expands the scope... Clean architecture really doesn't add that much overhead compared to the net gains you get in the future. You're essentially paying it forward.
@@lievendoclo7478 Yeap, it depends on a contract with your client. if you don't need to maintain the product after building the app based on the contract, you don't need to bother to add fancy architecture in the app. However, if you have to maintain the app in the long run, it would be better to have clean architecture.
@@ebichu8126 In my opinion, software should be written as if you would have to support it. Or as some once said, as if you were writing for a psychopath who knows where you live. Customers tend to change their mind about that too, and then then you’re stuck with all the shortcuts you’ve made. Clean architecture adds *maybe* a couple percents of overhead when it comes to lines of code, but the ROI is incredible. It’s a false flag to say that the other way is cheaper, because it’s not. Not at the end. We need to stop justifying writing bad code.
Also probably will take longer to design.
Congratulation Tom, that was an amazing session. I've learned so much.
My idea is that the use case should talk to domain service instead of talking directly to port. Each domain service will handle the business logic for each domain and it is the one that communicates with ports
Is this code example in github?
I think that ports usage is overengineering, and creating interface for each usecase too. Only worth idea is to split services into use cases, crud operations should be considered as one use case
It's not though, because when your app becomes more complex, u may want to separate commands (write operations) and queries (read operations), where commands would be executed via ORM and queries would be native SQL queries using an other technology or even an other database (aggregated read model).
I thought Java Spring Boot already had a small footprint for building applications. Was curious to see how the typical layers of controller, service, repository, persistence or JPA model would go. I've recently seen a .NET Core structure which has a domain, infrastructure and application tier. Have to say I'm not totally clear on business logic in the domain whilst micro-services are built in the application tier. My issues were that I had to know what the business requirement was and where we addressed it. How would I know how to implement it and send back a success or failure response in the form of a message.
I love hexagon this architecture
This is a great presentation. The only thing that is very debatable is putting the spring Service annotation in the use case service. And also the JsonCreator. As he said, it is his interpretation of the architecture.
It is not debatable, you can create your own annotation to suit your need, it is understandable.
But I don't really get the benefit of this structure with legacy MCV pattern, unless we need create more and more adapter to assume that our repository is not tied to JPA
@@xutiTrinh The benefit is that you abstract away the choice of technology from the business logic. So if you were to choose another repository implementation you can just add it with respect to the adapter contract. I don't agree with him having every persistence operation in its own adapter, just create one contract interface for all of them.
That said, you have a point. In most cases, this pattern is extremely over engineering and brings with it a lot of overhead code related to mapping and redundancy. Especially if you use a Microservice architecture where you keep the Microservice's size relative small in terms of functionality then just go for the ol' good MVC.
actually don't we have all these layers in each model?
The core should be independend of Frameworks. Why you use lombok in the Usecase?
Lombok just adds code to your class, no framework involved.
I couldn't find the repo on GitHub. Could someone please help me?
github.com/thombergs/buckpal
@@ThePitiYankee18 Actually it's this one github.com/thombergs/clean-timetracker
Would be good if code samples are shown
Hi should I use one usecase interface per one "service" (usecase implementation), or can I use a lot of interfaces with one implementation? because I have one service with a lot of usecases and I think it isn't a good approach
To be honest, that's a detail, but I like the fact that I can just see from the folder structure what my use cases are. If you look at SOLID principles, interface segregation supports the idea of having a SAM interface for use cases.
Very clear, thanks so much
Great!
just dont understand, but will come back latger
czcams.com/video/keaTZ9M_U1A/video.html
Yeah his coding examples were not great because they mixed too many unnecessary artefacts. He should've ripped out his "SelfValidating" interface, all his custom Spring annotations, etc and just focused on the Hexagonal components.
It also got too distracting with the random pitches for the Spring framework.
@@JonesDTaylor Thanks this is gold
I guess it is hard to grasp from the presentation. I found the book "Get your hands dirty on clean architecture" helpfful
@@KENTOSI any more resources you may suggest me? would be helpful. Thank you.
18:04 Clean Architecture
How can we deal with a big problem with many use cases ?
In this case, deal with your customer
j/k.
With many use cases combine then IMO it does not solve the complexity of structure, the purpose of hexagon is for developing isolation function at first but it is rare.
You gonna mess (or mix) ton of such use case soon
Well, you try to divide that big problem with the many use cases in smaller ones with each a subset of those use cases.
Further hello world architecture.
am
Very interesting topics...but please....a bit more of emphasis man!! Knowledge is a responsability....you cannot do a talk this important with so less energy. :/
Dont waste your time