Throughout the years, the Concentric Architectures (Onion, Hexagonal, Clean-..) have grown into the undisputed leader among backend systems architectures. With the rise of Domain-Driven Design, keeping your Domain ring 'agnostic' to the outside world has become the norm today. But history proved that any 'norm' in software architectures will cause overengineering if applied without criticism.
After a brief recap of these architectures, their pitfalls, and weaknesses, we'll see two alternatives that segregate code not in 'layers' or 'rings' but in vertical slices: Feature Slicing and Modular Monolith.
[Feature Slicing](vertical Slice Architecture) (aka *UseCase) has its own pitfalls and weaknesses, that we'll briefly review. But this will just warm us up for the next style.
Modular Monolith (aka Modulith) is an architecture style that helped many companies break their legacy codebases, and smoothly move to microservices. Most of the techniques discussed here can also come handy when one single microservice grew big and needs to be broken down.
Even more, greenfield projects today opt for this architecture instead of microservices, to avoid paying the high cost of distributability. Imagine cohesive but decoupled modules living in the same code base & deployment, but on which different teams work in harmony, delivering more value much faster than an equivalent microservice ecosystem.🦄
On the agenda:
- patterns to break data structures
- how to protect Domains inside modules
- communication patterns between modules
- breaking cyclic dependencies
Victor Rentea introduces himself as a Java Champion, trainer, and speaker who focuses on topics like Hibernate, Spring, Java 8/FP, architecture, clean code, unit testing, reactive programming, and Java performance. He advocates building a deep, rich domain model with value objects and entities that encapsulate logic and enforce invariants. The document provides guidance on applying principles like separating concerns with layers, dependency inversion, and avoiding anemic domain models in order to build flexible, testable systems that are decoupled from frameworks and external dependencies.
Clean Pragmatic Architecture - Avoiding a MonolithVictor Rentea
Talk built based on several of my trainings: http://www.victorrentea.ro/#training
Covers: Clean/Onion/Hexagonal Architecture, Domain Entities, Value Objects, Repository, Extract When it Grows Principle, Dependency Inversion Principle, Clean Code and Design Patterns.
These are the backing slides of the talks given at JPoint 2017 and Devoxx PL 2017: https://www.youtube.com/embed/4-4ahz7zDiQ
There's another talk about Clean Architecture, SOLID, and our approach at InfoJobs. If you need the slides, don't hesitate to fork https://github.com/schibsted-android-training/workshop-5
Clean architecture - Protecting the DomainVictor Rentea
The goal of architecture is to simplify the most complex parts of your logic. Any other goal should be secondary to this. The problem is that you can’t always anticipate where the complexity of your application will accumulate, especially when confronted with ever-changing requirements. The only way to keep your code simple is to gradually evolve the architecture without adding useless complexity up front, but always looking out for opportunities to break-down and refactor towards the most simple design that solves the problem. Drawing concepts from the Domain-Driven Development mindset, this talk summarizes the most important lessons learned designing and consulting many real-world projects. Along the way, you’ll hear about Value Objects and Entities, DTOs, Dependency Inversion Principle, Facades, the Onion Architecture and many pragmatic tips and tricks immediately applicable to your day-to-day work.
No Onions, No Tiers - An Introduction to Vertical Slice Architecture by Bill ...Alex Cachia
Vertical Slice Architecture helps us build maintainable applications by separating concerns around features rather than technical responsibilities allowing us to add features without modifying existing code.
Software Craftsmanship @Code Camp Festival 2022.pdfVictor Rentea
Decades ago, IT started as a single engineering practice, but over the years it grew increasingly fragmented. The overspecialization we face today, in the context of a management-first agile transformation leads to a lack of responsibility, blaming games, repeated patching, painful communication overhead, and fulminating costs. The software craftsmanship movement is rising in this post-agile world with professionals that take control of their careers and continuously learn in the pursuit of mastery. But changing mindset requires determined team efforts and communities, especially when working remotely. What techniques and tricks can you use to grow such a culture of learning in your team? Find out from the founder and lead of one of the largest software craftsmanship communities in the world.
This talk is about technical culture and attitude.
We like the architecture of our applications to revolve around the business logic, not around technical details (and especially not around the database).
In my team at Sky Network Services we use the Clean Architecture and it has given us a great deal of benefits: the business logic is explicit, we are free to change our technical decisions, the app is easy to test, working on it is faster and scalable, it’s hard to do the wrong thing, and many more.
But it comes at a cost, of course. In this talk I’ll tell you the story of our experience with Clean Architecture and give you some tips to get the most out of it.
Example Project
https://github.com/mattia-battiston/clean-architecture-example
Downloads
Online: https://goo.gl/DTxftJ
PDF: https://goo.gl/ZAtdBN
Powerpoint: https://goo.gl/D54wdZ (but you need to install these fonts to see it properly: https://goo.gl/iH8SO5)
Over the last year there has been a lot of buzz about Clean Architecture in the Android community, but what is Clean Architecture? How does it work? And should I be using it? Recently at Badoo we decided to rewrite our messenger component.
Over the years this core piece of functionality in our app has become large and unwieldy. We wanted to take a fresh approach to try and prevent this from happening again. We choose to use Clean Architecture to achieve our goal. This talk intends to share our journey from theory to implementation in an application with over 100 million downloads. By the end, you should not only understand what Clean Architecture is, but how to implement it, and whether you should.
Victor Rentea introduces himself as a Java Champion, trainer, and speaker who focuses on topics like Hibernate, Spring, Java 8/FP, architecture, clean code, unit testing, reactive programming, and Java performance. He advocates building a deep, rich domain model with value objects and entities that encapsulate logic and enforce invariants. The document provides guidance on applying principles like separating concerns with layers, dependency inversion, and avoiding anemic domain models in order to build flexible, testable systems that are decoupled from frameworks and external dependencies.
Clean Pragmatic Architecture - Avoiding a MonolithVictor Rentea
Talk built based on several of my trainings: http://www.victorrentea.ro/#training
Covers: Clean/Onion/Hexagonal Architecture, Domain Entities, Value Objects, Repository, Extract When it Grows Principle, Dependency Inversion Principle, Clean Code and Design Patterns.
These are the backing slides of the talks given at JPoint 2017 and Devoxx PL 2017: https://www.youtube.com/embed/4-4ahz7zDiQ
There's another talk about Clean Architecture, SOLID, and our approach at InfoJobs. If you need the slides, don't hesitate to fork https://github.com/schibsted-android-training/workshop-5
Clean architecture - Protecting the DomainVictor Rentea
The goal of architecture is to simplify the most complex parts of your logic. Any other goal should be secondary to this. The problem is that you can’t always anticipate where the complexity of your application will accumulate, especially when confronted with ever-changing requirements. The only way to keep your code simple is to gradually evolve the architecture without adding useless complexity up front, but always looking out for opportunities to break-down and refactor towards the most simple design that solves the problem. Drawing concepts from the Domain-Driven Development mindset, this talk summarizes the most important lessons learned designing and consulting many real-world projects. Along the way, you’ll hear about Value Objects and Entities, DTOs, Dependency Inversion Principle, Facades, the Onion Architecture and many pragmatic tips and tricks immediately applicable to your day-to-day work.
No Onions, No Tiers - An Introduction to Vertical Slice Architecture by Bill ...Alex Cachia
Vertical Slice Architecture helps us build maintainable applications by separating concerns around features rather than technical responsibilities allowing us to add features without modifying existing code.
Software Craftsmanship @Code Camp Festival 2022.pdfVictor Rentea
Decades ago, IT started as a single engineering practice, but over the years it grew increasingly fragmented. The overspecialization we face today, in the context of a management-first agile transformation leads to a lack of responsibility, blaming games, repeated patching, painful communication overhead, and fulminating costs. The software craftsmanship movement is rising in this post-agile world with professionals that take control of their careers and continuously learn in the pursuit of mastery. But changing mindset requires determined team efforts and communities, especially when working remotely. What techniques and tricks can you use to grow such a culture of learning in your team? Find out from the founder and lead of one of the largest software craftsmanship communities in the world.
This talk is about technical culture and attitude.
We like the architecture of our applications to revolve around the business logic, not around technical details (and especially not around the database).
In my team at Sky Network Services we use the Clean Architecture and it has given us a great deal of benefits: the business logic is explicit, we are free to change our technical decisions, the app is easy to test, working on it is faster and scalable, it’s hard to do the wrong thing, and many more.
But it comes at a cost, of course. In this talk I’ll tell you the story of our experience with Clean Architecture and give you some tips to get the most out of it.
Example Project
https://github.com/mattia-battiston/clean-architecture-example
Downloads
Online: https://goo.gl/DTxftJ
PDF: https://goo.gl/ZAtdBN
Powerpoint: https://goo.gl/D54wdZ (but you need to install these fonts to see it properly: https://goo.gl/iH8SO5)
Over the last year there has been a lot of buzz about Clean Architecture in the Android community, but what is Clean Architecture? How does it work? And should I be using it? Recently at Badoo we decided to rewrite our messenger component.
Over the years this core piece of functionality in our app has become large and unwieldy. We wanted to take a fresh approach to try and prevent this from happening again. We choose to use Clean Architecture to achieve our goal. This talk intends to share our journey from theory to implementation in an application with over 100 million downloads. By the end, you should not only understand what Clean Architecture is, but how to implement it, and whether you should.
The document discusses hexagonal architecture, also known as ports and adapters architecture. It is an alternative to traditional multi-layer architectures that aims to decouple the application core from external influences like databases, web frameworks, and other dependencies. The core domain logic is separated from external influences by defining application programming interfaces (APIs) called "ports" that external "adapters" implement. This allows the core to be developed and tested in isolation. The document provides an example implementation of a ticket management system using this architecture.
The tests are trying to tell you something@VoxxedBucharest.pptxVictor Rentea
If tests are hard to write, the production design is crappy - goes an old saying. Indeed, writing unit tests gives you one of the most comprehensive, yet brutal, feedback about the design of your production code, but if it comes too late, many developers can’t stand it anymore and they will either stop testing or test more superficially. At the other extreme, others struggle to write contrived, fragile tests full of mocks that end up frustrating more than helping them. This talk reviews the main hints that unit tests provide you, from the most obvious improvements to some of the most subtle design principles.
The document discusses the principles of clean architecture. It states that clean architecture aims to minimize human effort required to build and maintain software systems. It emphasizes that the core of an application should be its use cases rather than technical details like databases or frameworks. The architecture should clearly communicate the intent of the system. It also notes that dependencies should flow inward from outer layers like interfaces to inner layers containing core business logic and entities.
Domain Driven Design (DDD) is a topic that's been gaining a lot of popularity in both the Java and .NET camps recently. Entities, value types, repositories, bounded contexts and anti-corruption layers -- find out what all the buzz is about, and how establishing a domain model can help you combat complexity in your code.
Richard Dingwall is a .NET developer and blogger with a passion for architecture and maintainable code.
He is currently working at Provoke Solutions as lead developer on a six-month project introducing test-driven development (TDD) and domain-driven design (DDD) to a large ASP.NET ERP system.
An hour-long talk given at Wellington .NET user group, Sept 23 2009.
Kata: Hexagonal Architecture / Ports and Adaptersholsky
Hexagonal architecture is a software architecture pattern coined by Alistair Cockburn in 2005 that aims to make applications highly testable by separating the domain and application logic from the outer parts of an application like the user interface and databases. It uses port and adapter interfaces to connect the domain to the outside world which allows replacing external elements for testing purposes and makes the core logic independent of the outside tools and libraries. This decoupling brings benefits like easier testing without external elements, flexibility to change requirements and services, and emergent design.
This document discusses clean architecture principles for mobile applications. It describes common iOS code smells like god view controllers and tightly coupled code. The document introduces SOLID principles to improve code quality and testability. It then outlines architectural layers including entities, use cases, interface adapters, and frameworks. The layers are arranged based on the dependency rule, where inner layers do not depend on outer ones. Specific patterns like MVC, MVP, MVVM, VIPER and repositories are presented for each layer. The document emphasizes designing applications that are decoupled from frameworks and user interfaces to improve reusability and flexibility.
Slides of the talk held at JEEConf, Kiev and jPrime, Sofia. A personal view on the classic topics from the Uncle Bob's Clean Code bible, with some personal additions and tips&tricks. This topic actually represents the core of the training sessions that I provide as an independent trainer (www.victorrentea.ro)
The document discusses several object-oriented design principles including DRY (Don't Repeat Yourself), SLAP (Single Layer of Abstraction Principle), and OCP (Open-Closed Principle). It provides examples of code that violates these principles by duplicating logic, having methods that operate at different abstraction levels, and being closed for extension. The examples demonstrate how to refactor the code to follow the principles through techniques like extracting duplicate logic, breaking methods into smaller focused pieces, and designing classes to be open for extension without modifying existing code.
Lieven DOCLO gave a presentation on implementing Clean Architecture. Clean Architecture advocates separating domains, applications, and interfaces into separate layers. This allows the inner layers to be independent of the outer layers and frameworks. The presentation demonstrated creating building-related use cases and domain models, implementing repositories, and exposing use cases through REST endpoints. It discussed issues like decoupling tradeoffs, pragmatic compromises, and applying Clean Architecture to legacy projects.
The document discusses Domain-Driven Design (DDD). It explains that DDD focuses on properly modeling the problem domain and using this domain model to drive the software design. This involves developing a ubiquitous language within the bounded context of the domain model and ensuring consistency between this language, the domain model, and the software code. Patterns like entity, value object, aggregate, and repository can be used, but the domain model is the most important pattern in DDD.
How should a professional software developer behave in code? What guidelines should one follow? How should we name our constructs? What about OOP principles? What's their real use?
This classic training module in my training curricula is the cornerstone of my professionalism. These are my conduit guidelines at work. I've held this training > 10 times, including at Voxxed Days Bucharest 2016 and at a Bucharest Java User Group meetup.
Developing Event-driven Microservices with Event Sourcing & CQRS (gotoams)Chris Richardson
The document discusses how to develop event-driven microservices using event sourcing and Command Query Responsibility Segregation (CQRS). It describes event sourcing, where events are stored instead of the current application state. Services update their own state by subscribing to events. CQRS is used to separate read models from write models so that queries can be optimized with materialized views of aggregated data. Implementing queries in an event-sourced application involves using separate query-side microservices to update and retrieve materialized views based on domain events from the event store.
This document discusses the SOLID principles of object-oriented design:
- The Single Responsibility Principle states that a class should have one, and only one, reason to change.
- The Open/Closed Principle specifies that software entities should be open for extension but closed for modification.
- The Liskov Substitution Principle dictates that subclasses should behave in the same way as their parent classes.
- The Interface Segregation Principle indicates that client classes should not depend on interfaces they do not use.
- The Dependency Inversion Principle asserts that high-level modules should not depend on low-level modules, but both should depend on abstractions.
The presentation provides examples of
Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023Steve Pember
In this presentation we will present the general philosophy of Clean Architecture, Hexagonal Architecture, and Ports & Adapters: discussing why these approaches are useful and general guidelines for introducing them to your code. Chiefly, we will show how to implement these patterns within your Spring (Boot) Applications. Through a publicly available reference app, we will demonstrate what these concepts can look like within Spring and walkthrough a handful of scenarios: isolating core business logic, ease of testing, and adding a new feature or two.
Evolving a Clean, Pragmatic Architecture - A Craftsman's GuideVictor Rentea
This document outlines an agenda and presentation on clean code architecture. It discusses modeling data with entities and value objects, organizing logic by extracting services and applying the onion architecture. It emphasizes testing to reduce fear, and protecting developers through simplicity and avoiding overengineering. The presentation emphasizes keeping data transfer objects lightweight and external to the domain.
Functional Patterns with Java8 @Bucharest Java User GroupVictor Rentea
The slides for the presentation I gave at Bucharest Java User Group. This session was the largest Romanian Java community meetup ever organized until now.
Are you using Java8 Lambdas & Streams in your core business logic? Then you might be having this strange feeling that it’s not Java anymore: at times it’s cryptic, barely readable.. This was the topic of the workshop with the same name that I held at VoxxedDays Bucharest 2017. These are the slides backing the that workshop.
As a summary, the materials walk through the functional features of Java8, adding details along the way about how we can keep the code clean as we embrace the Java 8 features.
The entire desktop screencast + voice it's on youtube, here: https://youtu.be/uH9A37k2QkU
The document discusses the SOLID principles of object-oriented design:
1. The Single Responsibility Principle states that a class should have one, and only one, reason to change.
2. The Open-Closed Principle states that software entities should be open for extension but closed for modification. Behavior is changed through inheritance and composition rather than direct modification.
3. The Liskov Substitution Principle states that subclasses must behave in the same way as the base class so that the base class can be substituted wherever the subclass is expected.
4. The Interface Segregation Principle states that interfaces should be small and focused so that client classes do not depend on methods they do not use.
Domain-driven design (DDD) is an approach to software development that focuses on modeling a domain and implementing software that matches the complexity of that domain. It aims to tackle complexity in enterprise software by focusing design efforts on the core domain. Some key principles of DDD include building a ubiquitous language within a bounded context, using entities and value objects to model the domain, separating domain logic from application and presentation logic, and ensuring persistence ignorance. DDD can help improve understanding of the problem domain, create a shared language between technical and domain experts, and lead to a model-driven design rather than one driven by tools or databases.
This document discusses Domain-Driven Design (DDD) and provides guidance on its implementation. It explains that DDD focuses on understanding and modeling the core domain of a business to manage complexity. It recommends dividing a domain into subdomains and identifying the core domain. It also discusses building models through collaboration and ensuring the code model aligns with the conceptual model. The document provides an overview of key DDD concepts like bounded contexts, aggregates, domain events, and tactical patterns to structure the solution space.
How can we quickly tell what an application is about? How can we quickly tell what it does? How can we distinguish business concepts from architecture clutter? How can we quickly find the code we want to change? How can we instinctively know where to add code for new features? Purely looking at unit tests is either not possible or too painful. Looking at higher-level tests can take a long time and still not give us the answers we need. For years, we have all struggled to design and structure projects that reflect the business domain.
In this talk Sandro will be sharing how he designed the last application he worked on, twisting a few concepts from Domain-Driven Design, properly applying MVC, borrowing concepts from CQRS, and structuring packages in non-conventional ways. Sandro will also be touching on SOLID principles, Agile incremental design, modularisation, and testing. By iteratively modifying the project structure to better model the product requirements, he has come up with a design style that helps developers create maintainable and domain-oriented software.
Testing is fundamental in software development. Quality gates demand high coverage levels, pull requests need sufficient tests, leading to teams spending considerable time writing and maintaining them. But are we using our tests to their full potential?
'If code is hard to test, the design can be improved'. Starting from this mantra, this deep-dive session unveils hints to simplify code, break-down complexity, and effectively use functional programming. We'll delve into topics like fixture creep, partial mocks, onion architecture, and pure functions, providing numerous best practices and practical tips for your testing.
Be warned: This session may significantly disrupt your work routine and will likely change how you see testing. Attend at your own risk.
The document discusses hexagonal architecture, also known as ports and adapters architecture. It is an alternative to traditional multi-layer architectures that aims to decouple the application core from external influences like databases, web frameworks, and other dependencies. The core domain logic is separated from external influences by defining application programming interfaces (APIs) called "ports" that external "adapters" implement. This allows the core to be developed and tested in isolation. The document provides an example implementation of a ticket management system using this architecture.
The tests are trying to tell you something@VoxxedBucharest.pptxVictor Rentea
If tests are hard to write, the production design is crappy - goes an old saying. Indeed, writing unit tests gives you one of the most comprehensive, yet brutal, feedback about the design of your production code, but if it comes too late, many developers can’t stand it anymore and they will either stop testing or test more superficially. At the other extreme, others struggle to write contrived, fragile tests full of mocks that end up frustrating more than helping them. This talk reviews the main hints that unit tests provide you, from the most obvious improvements to some of the most subtle design principles.
The document discusses the principles of clean architecture. It states that clean architecture aims to minimize human effort required to build and maintain software systems. It emphasizes that the core of an application should be its use cases rather than technical details like databases or frameworks. The architecture should clearly communicate the intent of the system. It also notes that dependencies should flow inward from outer layers like interfaces to inner layers containing core business logic and entities.
Domain Driven Design (DDD) is a topic that's been gaining a lot of popularity in both the Java and .NET camps recently. Entities, value types, repositories, bounded contexts and anti-corruption layers -- find out what all the buzz is about, and how establishing a domain model can help you combat complexity in your code.
Richard Dingwall is a .NET developer and blogger with a passion for architecture and maintainable code.
He is currently working at Provoke Solutions as lead developer on a six-month project introducing test-driven development (TDD) and domain-driven design (DDD) to a large ASP.NET ERP system.
An hour-long talk given at Wellington .NET user group, Sept 23 2009.
Kata: Hexagonal Architecture / Ports and Adaptersholsky
Hexagonal architecture is a software architecture pattern coined by Alistair Cockburn in 2005 that aims to make applications highly testable by separating the domain and application logic from the outer parts of an application like the user interface and databases. It uses port and adapter interfaces to connect the domain to the outside world which allows replacing external elements for testing purposes and makes the core logic independent of the outside tools and libraries. This decoupling brings benefits like easier testing without external elements, flexibility to change requirements and services, and emergent design.
This document discusses clean architecture principles for mobile applications. It describes common iOS code smells like god view controllers and tightly coupled code. The document introduces SOLID principles to improve code quality and testability. It then outlines architectural layers including entities, use cases, interface adapters, and frameworks. The layers are arranged based on the dependency rule, where inner layers do not depend on outer ones. Specific patterns like MVC, MVP, MVVM, VIPER and repositories are presented for each layer. The document emphasizes designing applications that are decoupled from frameworks and user interfaces to improve reusability and flexibility.
Slides of the talk held at JEEConf, Kiev and jPrime, Sofia. A personal view on the classic topics from the Uncle Bob's Clean Code bible, with some personal additions and tips&tricks. This topic actually represents the core of the training sessions that I provide as an independent trainer (www.victorrentea.ro)
The document discusses several object-oriented design principles including DRY (Don't Repeat Yourself), SLAP (Single Layer of Abstraction Principle), and OCP (Open-Closed Principle). It provides examples of code that violates these principles by duplicating logic, having methods that operate at different abstraction levels, and being closed for extension. The examples demonstrate how to refactor the code to follow the principles through techniques like extracting duplicate logic, breaking methods into smaller focused pieces, and designing classes to be open for extension without modifying existing code.
Lieven DOCLO gave a presentation on implementing Clean Architecture. Clean Architecture advocates separating domains, applications, and interfaces into separate layers. This allows the inner layers to be independent of the outer layers and frameworks. The presentation demonstrated creating building-related use cases and domain models, implementing repositories, and exposing use cases through REST endpoints. It discussed issues like decoupling tradeoffs, pragmatic compromises, and applying Clean Architecture to legacy projects.
The document discusses Domain-Driven Design (DDD). It explains that DDD focuses on properly modeling the problem domain and using this domain model to drive the software design. This involves developing a ubiquitous language within the bounded context of the domain model and ensuring consistency between this language, the domain model, and the software code. Patterns like entity, value object, aggregate, and repository can be used, but the domain model is the most important pattern in DDD.
How should a professional software developer behave in code? What guidelines should one follow? How should we name our constructs? What about OOP principles? What's their real use?
This classic training module in my training curricula is the cornerstone of my professionalism. These are my conduit guidelines at work. I've held this training > 10 times, including at Voxxed Days Bucharest 2016 and at a Bucharest Java User Group meetup.
Developing Event-driven Microservices with Event Sourcing & CQRS (gotoams)Chris Richardson
The document discusses how to develop event-driven microservices using event sourcing and Command Query Responsibility Segregation (CQRS). It describes event sourcing, where events are stored instead of the current application state. Services update their own state by subscribing to events. CQRS is used to separate read models from write models so that queries can be optimized with materialized views of aggregated data. Implementing queries in an event-sourced application involves using separate query-side microservices to update and retrieve materialized views based on domain events from the event store.
This document discusses the SOLID principles of object-oriented design:
- The Single Responsibility Principle states that a class should have one, and only one, reason to change.
- The Open/Closed Principle specifies that software entities should be open for extension but closed for modification.
- The Liskov Substitution Principle dictates that subclasses should behave in the same way as their parent classes.
- The Interface Segregation Principle indicates that client classes should not depend on interfaces they do not use.
- The Dependency Inversion Principle asserts that high-level modules should not depend on low-level modules, but both should depend on abstractions.
The presentation provides examples of
Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023Steve Pember
In this presentation we will present the general philosophy of Clean Architecture, Hexagonal Architecture, and Ports & Adapters: discussing why these approaches are useful and general guidelines for introducing them to your code. Chiefly, we will show how to implement these patterns within your Spring (Boot) Applications. Through a publicly available reference app, we will demonstrate what these concepts can look like within Spring and walkthrough a handful of scenarios: isolating core business logic, ease of testing, and adding a new feature or two.
Evolving a Clean, Pragmatic Architecture - A Craftsman's GuideVictor Rentea
This document outlines an agenda and presentation on clean code architecture. It discusses modeling data with entities and value objects, organizing logic by extracting services and applying the onion architecture. It emphasizes testing to reduce fear, and protecting developers through simplicity and avoiding overengineering. The presentation emphasizes keeping data transfer objects lightweight and external to the domain.
Functional Patterns with Java8 @Bucharest Java User GroupVictor Rentea
The slides for the presentation I gave at Bucharest Java User Group. This session was the largest Romanian Java community meetup ever organized until now.
Are you using Java8 Lambdas & Streams in your core business logic? Then you might be having this strange feeling that it’s not Java anymore: at times it’s cryptic, barely readable.. This was the topic of the workshop with the same name that I held at VoxxedDays Bucharest 2017. These are the slides backing the that workshop.
As a summary, the materials walk through the functional features of Java8, adding details along the way about how we can keep the code clean as we embrace the Java 8 features.
The entire desktop screencast + voice it's on youtube, here: https://youtu.be/uH9A37k2QkU
The document discusses the SOLID principles of object-oriented design:
1. The Single Responsibility Principle states that a class should have one, and only one, reason to change.
2. The Open-Closed Principle states that software entities should be open for extension but closed for modification. Behavior is changed through inheritance and composition rather than direct modification.
3. The Liskov Substitution Principle states that subclasses must behave in the same way as the base class so that the base class can be substituted wherever the subclass is expected.
4. The Interface Segregation Principle states that interfaces should be small and focused so that client classes do not depend on methods they do not use.
Domain-driven design (DDD) is an approach to software development that focuses on modeling a domain and implementing software that matches the complexity of that domain. It aims to tackle complexity in enterprise software by focusing design efforts on the core domain. Some key principles of DDD include building a ubiquitous language within a bounded context, using entities and value objects to model the domain, separating domain logic from application and presentation logic, and ensuring persistence ignorance. DDD can help improve understanding of the problem domain, create a shared language between technical and domain experts, and lead to a model-driven design rather than one driven by tools or databases.
This document discusses Domain-Driven Design (DDD) and provides guidance on its implementation. It explains that DDD focuses on understanding and modeling the core domain of a business to manage complexity. It recommends dividing a domain into subdomains and identifying the core domain. It also discusses building models through collaboration and ensuring the code model aligns with the conceptual model. The document provides an overview of key DDD concepts like bounded contexts, aggregates, domain events, and tactical patterns to structure the solution space.
How can we quickly tell what an application is about? How can we quickly tell what it does? How can we distinguish business concepts from architecture clutter? How can we quickly find the code we want to change? How can we instinctively know where to add code for new features? Purely looking at unit tests is either not possible or too painful. Looking at higher-level tests can take a long time and still not give us the answers we need. For years, we have all struggled to design and structure projects that reflect the business domain.
In this talk Sandro will be sharing how he designed the last application he worked on, twisting a few concepts from Domain-Driven Design, properly applying MVC, borrowing concepts from CQRS, and structuring packages in non-conventional ways. Sandro will also be touching on SOLID principles, Agile incremental design, modularisation, and testing. By iteratively modifying the project structure to better model the product requirements, he has come up with a design style that helps developers create maintainable and domain-oriented software.
Testing is fundamental in software development. Quality gates demand high coverage levels, pull requests need sufficient tests, leading to teams spending considerable time writing and maintaining them. But are we using our tests to their full potential?
'If code is hard to test, the design can be improved'. Starting from this mantra, this deep-dive session unveils hints to simplify code, break-down complexity, and effectively use functional programming. We'll delve into topics like fixture creep, partial mocks, onion architecture, and pure functions, providing numerous best practices and practical tips for your testing.
Be warned: This session may significantly disrupt your work routine and will likely change how you see testing. Attend at your own risk.
1. The document discusses object-oriented programming concepts like abstraction, encapsulation, inheritance, polymorphism, and dynamic binding.
2. It then provides details on the history and features of Java, including how Java code is compiled and run on the Java Virtual Machine.
3. Core object-oriented features of Java like classes, objects, constructors, and method overloading are explained.
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024Victor Rentea
The microservices honeymoon is over. When starting a new project or revamping a legacy monolith, teams started looking for alternatives to microservices. The Modular Monolith, or 'Modulith', is an architecture that reaps the benefits of (vertical) functional decoupling without the high costs associated with separate deployments. This talk will delve into the advantages and challenges of this progressive architecture, beginning with exploring the concept of a 'module', its internal structure, public API, and inter-module communication patterns. Supported by spring-modulith, the talk provides practical guidance on addressing the main challenges of a Modultith Architecture: finding and guarding module boundaries, data decoupling, and integration module-testing. You should not miss this talk if you are a software architect or tech lead seeking practical, scalable solutions.
About the author
With two decades of experience, Victor is a Java Champion working as a trainer for top companies in Europe. Five thousands developers in 120 companies attended his workshops, so he gets to debate every week the challenges that various projects struggle with. In return, Victor summarizes key points from these workshops in conference talks and online meetups for the European Software Crafters, the world’s largest developer community around architecture, refactoring, and testing. Discover how Victor can help you on victorrentea.ro : company training catalog, consultancy and YouTube playlists.
Tampere Docker meetup - Happy 5th Birthday DockerSakari Hoisko
Part of official docker meetup events by Docker Inc.
https://events.docker.com/events/docker-bday-5/
Meetup event:
https://www.meetup.com/Docker-Tampere/events/248566945/
Montreal Kubernetes Meetup: Developer-first workflows (for microservices) on ...Ambassador Labs
1. The document discusses developer-first workflows for building and operating microservices on Kubernetes.
2. It recommends creating self-sufficient, autonomous teams and using Kubernetes, Docker, and Envoy to provide the basic infrastructure primitives needed for distributed workflows.
3. The strategies suggested depend on the service maturity level and include using similar development and production environments for prototyping, implementing software redundancy for production services, and defining service level objectives and network observability for internal dependencies.
(IMPROVED VERSION FROM GEECON)
How can we quickly tell what an application is about? How can we quickly tell what it does? How can we distinguish business concepts from architecture clutter? How can we quickly find the code we want to change? How can we instinctively know where to add code for new features? Purely looking at unit tests is either not possible or too painful. Looking at higher-level tests can take a long time and still not give us the answers we need. For years, we have all struggled to design and structure projects that reflect the business domain.
In this talk Sandro will be sharing how he designed the last application he worked on, twisting a few concepts from Domain-Driven Design, properly applying MVC, borrowing concepts from CQRS, and structuring packages in non-conventional ways. Sandro will also be touching on SOLID principles, Agile incremental design, modularisation, and testing. By iteratively modifying the project structure to better model the application requirements, he has come up with a design style that helps developers create maintainable and domain-oriented software.
Presentation from RedDotRubyConf 2011 in Singapore. It explains multi-tenancy and why it is increasingly required for Rails development. Four of the many approaches are covered in some detail (including what resources we have available for re-use) and I end with a naive question (& call to action?) .. "Isn't it about time there was a 'Rails Way'?"
This document introduces Interaction-Driven Design (IDD) and discusses best practices for application structure and testing strategies when using this approach. It recommends starting the design process from the user interactions or actions needed, which will help define domain concepts and emerging entities. The core domain model should be separated from infrastructure implementations. Testing strategies covered include user journey tests at the application level, acceptance tests at the action level, integration tests at boundaries, and unit tests at the class level. Dependencies should be mocked or stubbed at different test levels.
DDD, CQRS and testing with ASP.Net MVCAndy Butland
This document provides an overview of a presentation on Domain Driven Design (DDD), Command Query Responsibility Segregation (CQRS), and testing with ASP.Net MVC. It introduces the presenter and gives an outline of the topics to be covered, including implementing DDD with ASP.Net MVC and Entity Framework, using a mediator pattern for CQRS, and unit testing models, queries, and commands. References are given to other authors and resources that influenced the approaches and implementations discussed in the presentation.
The document provides recipes for building CQRS architectures. It begins with an introduction and agenda. Lesson 1 discusses a basic layered architecture, noting its limitations in scalability and evolvability. Lesson 2 introduces n-layered architecture with dependency injection to improve decoupling but it also has scalability issues. Lesson 3 explains the Command Query Responsibility Segregation (CQRS) pattern, separating read and write operations for improved scalability and flexibility. It provides code examples of implementing CQRS. The document aims to help architects evolve monolithic systems to more scalable and maintainable architectures.
Avoiding the domino effect in our [micro]services (SOLID at macro-design level)CodelyTV
How can we apply SOLID principles to a macro-design level in our [micro]services architectures?
In this talk we will see a problem-solution approach on how we deal with different kinds of load for our different services in order to avoid a domino effect while having peaks of request in one of our services. We'll do so using Domain Events and Message Queues such as RabbitMQ and AWS SNS-SQS.
Spanish resources:
* Hexagonal Architecture course: https://pro.codely.tv/library/arquitectura-hexagonal/66748/about/
* CQRS course: https://pro.codely.tv/library/cqrs-command-query-responsibility-segregation-3719e4aa/62554/about/
* HTTP API with Scala course: https://pro.codely.tv/library/api-http-con-scala-y-akka/66747/about/
* Testing in CQRS architectures talk: https://www.youtube.com/watch?v=cw6Va1ZW7iI
* We broke up with the monolith, and started dating event sourcing slides: https://www.slideshare.net/JavierCane/we-broke-up-with-the-monolith-and-started-dating-eventsourcing-symfonycat
English resources:
* The anatomy of Domain Event: blog.arkency.com/2016/05/the-anatomy-of-domain-event/
* Versioning in an Event Sourced System book: https://leanpub.com/esversioning
* RabbitMQ Simulator: tryrabbitmq.com
* A Series of Fortunate Events slides: https://www.slideshare.net/matthiasnoback/a-series-of-fortunate-events-symfony-camp-sweden-2014
Elements of DDD with ASP.NET MVC & Entity Framework Code First v2Enea Gabriel
The document discusses Domain-Driven Design (DDD) with ASP.NET MVC and Entity Framework Code First. It covers challenges with traditional architecture like layers coupling and where to implement business rules. DDD is presented as a new default architecture where the database is not the primary focus, layers are loosely coupled, and business rules are within the application domain. Today's tools like ASP.NET MVC, dependency injection frameworks, and Entity Framework Code First are discussed. A demo is presented and conclusions recommend focusing on analyzing dependencies, designing the domain, and doing refactoring and unit testing.
IBM Think Session 8598 Domino and JavaScript Development MasterClassPaul Withers
Session from IBM Think 2018. Note: the architecture used is an extreme case of what's possible (and it could go further), rather than a real-world expectation
Inria Tech Talk : Comment améliorer la qualité de vos logiciels avec STAMPStéphanie Roger
Que vous soyez développeur ou entrepreneur, découvrez le projet STAMP piloté par Inria, l'institut national de recherche dédié aux sciences du numérique.
Reactive programming allows for non-blocking and concurrent executions. It is designed to be more efficient by using fewer threads and less memory. This makes applications more resilient and scalable to handle high connection volumes and traffic variability. The developer experience is improved through actionable stacktraces and debugging of reactive flows.
Since the introduction of replication in MySQL, users have been trying to automate the promotion of a replica to a primary as well as automating the failover of TCP connections from one database server to another in the event of a database failure: planned or unplanned. For over a decade, users and organizations have designed various types of solutions to achieve this. Though, many of these solutions were done manually or were using third party software, mostly open source, to automate and integrate various architectures.
For more than 5 years now, MySQL offers complete and very easy-to-use solutions to set up database architectures that provide High-Availability and recently added Disaster Recovery capabilities. Completely built in-house and supported by Oracle, many enterprises large and small have adopted these solutions into business-critical applications.
Business requirements dictate what type of database architecture is required for your system. Disaster tolerance is key and can be measured at different levels: data loss, data availability, and uptime. In this session, the various MySQL Database Architecture solutions will be covered to help you choose the right solution based on your business requirements
Reactive Microservices with Spring 5: WebFlux Trayan Iliev
On November 27 Trayan Iliev from IPT presented “Reactive microservices with Spring 5: WebFlux” @Dev.bg in Betahaus Sofia. IPT – Intellectual Products & Technologies has been organizing Java & JavaScript trainings since 2003.
Spring 5 introduces a new model for end-to-end functional and reactive web service programming with Spring 5 WebFlow, Spring Data & Spring Boot. The main topics include:
– Introduction to reactive programming, Reactive Streams specification, and project Reactor (as WebFlux infrastructure)
– REST services with WebFlux – comparison between annotation-based and functional reactive programming approaches for building.
– Router, handler and filter functions
– Using reactive repositories and reactive database access with Spring Data. Building end-to-end non-blocking reactive web services using Netty-based web runtime
– Reactive WebClients and integration testing. Reactive WebSocket support
– Realtime event streaming to WebClients using JSON Streams, and to JS client using SSE.
Talha Ahmed Sheikh is a Microsoft Certified IT Professional with over 2 years of experience in system administration, infrastructure solutions design, and virtualization. He has expertise in Windows server, Exchange server, Hyper-V, Active Directory, and networking. He is seeking new opportunities as a system engineer where he can utilize his technical skills and experience managing IT systems and networks.
Tracing the root cause of a performance issue requires a lot of patience, experience, and focus. It’s so hard that we sometimes attempt to guess by trying out tentative fixes, but that usually results in frustration, messy code, and a considerable waste of time and money. This talk explains how to correctly zoom in on a performance bottleneck using three levels of profiling: distributed tracing, metrics, and method profiling. After we learn to read the JVM profiler output as a flame graph, we explore a series of bottlenecks typical for backend systems, like connection/thread pool starvation, invisible aspects, blocking code, hot CPU methods, lock contention, and Virtual Thread pinning, and we learn to trace them even if they occur in library code you are not familiar with. Attend this talk and prepare for the performance issues that will eventually hit any successful system.
About authorWith two decades of experience, Victor is a Java Champion working as a trainer for top companies in Europe. Five thousands developers in 120 companies attended his workshops, so he gets to debate every week the challenges that various projects struggle with. In return, Victor summarizes key points from these workshops in conference talks and online meetups for the European Software Crafters, the world’s largest developer community around architecture, refactoring, and testing. Discover how Victor can help you on victorrentea.ro : company training catalog, consultancy and YouTube playlists.
The network is reliable, has zero latency, with infinite, free bandwidth... And then you wake up. The plan was to go to microservices to build those reliable, super-scalable systems you saw in the ad. But your systems only communicate over synchronous protocols and the team never had a serious discussion about timeouts, retries, circuit breakers, and bulkhead patterns. If that’s your crude reality, please attend this session!
One of the many challenges of a distributed architecture is preserving the consistency of data across different systems. During this one-hour presentation, we are going to explore a number of strategies for maintaining consistency, going from the most basic options up to an automated recovery mechanism using compensations and reservations - what’s commonly referred to as a “saga” pattern. Our journey will be based on a hypothetical food delivery application on which we will analyze various decisions and their tradeoffs. The discussion will stay at an abstract, architectural level for the most part, with only a few code examples.
In the agenda:
- Idempotency and Retries
- 2 Phase Commit
- Eventual Consistency
- Compensations
- Reservations
- The Saga Pattern
Clean Code @Voxxed Days Cluj 2023 - opening KeynoteVictor Rentea
Clean Code principles have become a cornerstone of professional developer teams worldwide. But frameworks and languages have evolved, and so have the challenges we’re facing today while crafting modern applications. Single-page apps, extremely DRY code, microservices, excessive functional programming, and reactive flows have all taken their toll on our code quality. Hop aboard this roundtrip of the most damaging Code Smells as of 2023 and fill your toolbox with a load of practical tricks you can immediately apply to your day-to-day work. All in an entertaining show spiced with live-coding moments.
Testing strategies for modern software architectures are evolving. As we transition from monolithic structures to team-sized microservices with crisp APIs aligned to bounded contexts, we encounter more stable testing surfaces. This shift leads many high-performing teams to favor integration tests over fine-grained, brittle unit tests. These integration tests, which are closer to the functional requirements, prove more trustworthy and are more resilient to internal refactoring, though they may come with a higher cost. In a vivid and engaging style, this talk addresses the primary challenges of integration testing in the microservices era: cognitive overload, test isolation, and test execution speed. Join the testing revolution and discover how to enhance your team's testing efficiency and effectiveness.
Ready for a deep dive into the world's most challenging programming paradigm? Reactive programming can simplify asynchronous and event-driven applications, but without a strong understanding, it can lead to frustration, recurring patchwork, missed deadlines, and costly bugs.
In this intensive three-hour session, we'll transition a traditional Spring application to WebFlux, revealing patterns and aanti-patterns when working with repositories, REST APIs, queues, and legacy libraries. You'll gain a clear understanding of often overlooked but critical aspects like subscribe signal, errors, cancellation, and signal loss. As a bonus, we'll debate the future of Reactive vs Virtual Threads, production-ready in Java 21.
This session is crucial for developers already working with reactive programming or those intending to make the leap.
The biggest challenge in performance tuning is identifying the root cause of the bottleneck. Once you find it, the fix often becomes trivial. However, this detective work takes patience, skills, and effort, so we often attempt to guess the cause, by trying out tentative fixes. The result: messy code, waste of time and money, and frustration. During this talk you will learn how to correctly zoom in on the bottleneck using three levels of profiling: distributed tracing with Zipkin, metrics with Micrometer, and profiling with the Java Flight Recorder already built into your JVM. We’ll focus on the latter and learn how to read a flame graph to trace some common issues of backend systems like connection/thread pool starvation, time-consuming aspects, hot methods, and lock contention, even if these occur in library code you did not write.
Slides for my presentation about OAuth, going in depth in the details of the Authorization Code Grant and PKCE, also describing several security threats to OAuth
Tests are hard to write if the production design is crappy - goes an old saying. Indeed, writing unit tests gives you one of the most comprehensive, yet brutal, feedback about the design of your production code, but if it comes too late, many developers can’t take it and they will either stop testing or test superficially. At the other end, others struggle to write contrieved, fragile tests full of mocks that end up frustrating more than helping them. This talk reviews the main hints that unit tests provide you, from the most obvious improvements to some of the most subtle design principles.
Decades ago, IT started as a single engineering practice, but as time passed by it got increasingly fragmented. Conflicts broke out between testers vs developers vs sysadmins vs DBAs vs many other roles. Recently, developers themselves split into many subspecialties like backend/frontend/iOS/Android/microservices/functions/etc. The overspecialization we face today causes huge communication overhead, a low bus factor, lack of responsibility, blaming, repeated isolated patching and fulminating costs. The software craftsmanship movement is rising in this post-agile world with professionals eager to take control of their careers and continuously learn in the pursuit of mastery. This talk will show you practical ways in which to seed a continuous learning culture in your team or company, and foster the enthusiasm of your developers.
Refactoring blockers and code smells @jNation 2021Victor Rentea
The only way to survive in a codebase is by refactoring continuously. We know that since the Extreme Programming days. But what stops us from doing so today? In this talk, Victor summarizes what he learned discussing Clean Code and Refactoring with hundreds of teams throughout the world. You'll find ideas to tackle a broad spectrum of factors: technical, cultural, psychological, emotional, social, and even political. Using these you might unlock the freedom to refactor for you and your colleagues.
After this roundtrip, the talk briefly overviews several of the most dangerous code smells in the projects today: God Class, Duplicated Code vs Divergent Code, Temporal Coupling, Middle Man, Speculative Generality, Mutable Long-Lived State, Comments, and more. For each of them we’ll discuss a typical workaround, plus several subtleties and variations.
Hibernate and Spring - Unleash the MagicVictor Rentea
This document provides an overview of several Java technologies:
- JPA Auditing for tracking entity creation/modification dates and users
- Domain Events in DDD for triggering processing across aggregates
- javax.validation for validating entities before database writes
- Spring Data Repos for implementing repositories with query methods and custom logic
It also briefly discusses JPA auditing implementation, domain event publishing, custom validators, and the @NonNullApi annotation for preventing null returns from repositories.
Integration testing with spring @JAX MainzVictor Rentea
Our sleep is better with longer-scoped tests. Our life is brighter if we don’t rely heavily on fine-grained tests that break whenever we refactor even the smallest detail. I’m talking about tilting the balance towards more integration than unit testing. And for that, let’s look at the testing features offered by the most used Java Framework today. We’ll see how to write fake test implementations, how to mock an unwanted Spring bean, what a Transactional Test is, and if and how to test your web endpoints. Along the way, we’ll also see Flaky tests, and discuss best practices about integration testing – all in an entertaining live coding session.
Your takeaways from this talk will be a lot of good practices and techniques directly applicable to your day-to-day project.
The Proxy Fairy and the Magic of Spring @JAX Mainz 2021Victor Rentea
You can only claim you know Spring if you fully understand the Proxy design pattern and how the framework uses it to do its magic. Join this live coding session to explore 6 ways of intercepting method calls that you can use to cast your own spells and dramatically simplify your codebase.
Grab a strong coffee and prepare yourself for a whirlwind of **live-coding**, interwoven with **deep theoretical concepts and implementation details** that you need to master if you are using the Spring Framework. We’ll start from a Decorator pattern implementation, proving 2 ways to wire it with Spring, then move to bare-hands interface proxies, concrete classes proxies, @Aspect applied to custom annotations, plus some standard off-the-shelf Spring aspects.
Join this talk and learn real-world best practices to use with Aspects, design hints, under-the-hood implementation details, debugging tips, and performance impact of aspects. All in an interactive, entertaining, and extremely dynamic session.
Integration testing with spring @snow oneVictor Rentea
This document provides an overview of integration testing strategies and techniques. It discusses the differences between unit tests and integration tests, including that integration tests involve multiple layers and dependencies like databases, files, and web services, making them slower and more fragile. It also covers best practices for integration tests such as using an in-memory database, WireMock for stubbing external services, transaction management, and strategies for cleaning up after tests.
Pure functions and immutable objects @dev nexus 2021Victor Rentea
aaaaThis presentation focuses on two of the most advanced design tools in your toolbox, whatever the language or framework you might be using. After understanding the basics, we'll see how these concepts can be used in real-world scenarios to simplify those several most complex use-cases in your application. At the end of a mix of slides and live-coding, you'll finally understand the power of these ideas and become prepared to apply them in your day-to-day work.
Along the way, we'll introduce concepts like Side Effects, Idempotency, Referential Transparency, Pure Functions and Deep/Shallow Immutability. Also, we'll talk about the powerful Functional Code / Imperative Shell architecture that you can use for your complex workflows.
Prepare for an entertaining, highly interactive session that will answer all your questions.
Written in Java and spoken in English.
This document describes Victor Rentea, an independent trainer and founder of the Bucharest Software Craftsmanship Community who has provided technical training to over 2000 developers over 8 years. It promotes Victor Rentea's training services on topics like Hibernate, Spring, Java performance, reactive programming, design patterns, clean code, refactoring, and unit testing in any language. The document also provides brief summaries of test-driven development and the three rules of TDD according to Uncle Bob, as well as a definition of code golf.
Definitive Guide to Working With Exceptions in Java - takj at Java Champions ...Victor Rentea
A Pragmatic approach to work with exceptions in Java. Talk recording: https://www.youtube.com/watch?v=LRwCE7GreSM&feature=youtu.be
Discussing checked exceptions, Vavr, Lombok, and JooL library, Spring Framework and many more.
Supporting in-depth article series: https://victorrentea.ro/blog/exception-handling-guide-in-java/
Don't Be Mocked by your Mocks - Best Practices using MocksVictor Rentea
Do you ❤️ Mocks? When you write your first unit tests, especially on older codebases, mocking foreign code is key to survival. But as you grow older in the craft, you start piling up hours and days wasted to refactor fragile tests or to fix bugs that those heavy mock-based tests didn't catch. And so you start looking at Mocks differently.
Let's go through the key factors to consider to strike the optimal balance between what needs to be mocked away and what code should be tested in integration. There's sometimes a fine line there, often interwoven with strong emotions:
"Why am I testing this?"
"Argh… these tests take too long"
"Can this ever really break?"
etc...
Among the points that we'll touch on:
- Mocks vs Refactoring
- Mocks vs Reliability
- Fine vs Coarse Mocks
- Reproducibility
- Partial Mocks
- Mocking Statics
- Alternatives to Mocks
Speakers: Victor Rentea
Victor is a Java Champion and Independent Trainer with an impressive experience: thousands of developers in dozens of companies trained in dedicated company sessions. He is the founder of one of the largest developer communities in Romania, Bucharest Software Craftsmanship Community and a top international conference speaker.
To find more about him, join a live masterclass or call him in for a company dedicated training: victorrentea.ro
First, what are they? And why they are important? What do they allow us to do, and what problems do they shield us from?
After this talk, you'll inevitably fall in love with pure functions and immutable objects. We'll see how to implement them in Java, in the most geek ways possible, concerned about long-term maintainability of the code. Oh, and we'll also have Lombok and records along the way, plus lots of fun while tasting a bit of "a senior developer's night-life".
Given at jLove Dec 2020
Unveiling the Advantages of Agile Software Development.pdfbrainerhub1
Learn about Agile Software Development's advantages. Simplify your workflow to spur quicker innovation. Jump right in! We have also discussed the advantages.
E-commerce Development Services- Hornet DynamicsHornet Dynamics
For any business hoping to succeed in the digital age, having a strong online presence is crucial. We offer Ecommerce Development Services that are customized according to your business requirements and client preferences, enabling you to create a dynamic, safe, and user-friendly online store.
Mobile app Development Services | Drona InfotechDrona Infotech
Drona Infotech is one of the Best Mobile App Development Company In Noida Maintenance and ongoing support. mobile app development Services can help you maintain and support your app after it has been launched. This includes fixing bugs, adding new features, and keeping your app up-to-date with the latest
Visit Us For :
SOCRadar's Aviation Industry Q1 Incident Report is out now!
The aviation industry has always been a prime target for cybercriminals due to its critical infrastructure and high stakes. In the first quarter of 2024, the sector faced an alarming surge in cybersecurity threats, revealing its vulnerabilities and the relentless sophistication of cyber attackers.
SOCRadar’s Aviation Industry, Quarterly Incident Report, provides an in-depth analysis of these threats, detected and examined through our extensive monitoring of hacker forums, Telegram channels, and dark web platforms.
Artificia Intellicence and XPath Extension FunctionsOctavian Nadolu
The purpose of this presentation is to provide an overview of how you can use AI from XSLT, XQuery, Schematron, or XML Refactoring operations, the potential benefits of using AI, and some of the challenges we face.
Measures in SQL (SIGMOD 2024, Santiago, Chile)Julian Hyde
SQL has attained widespread adoption, but Business Intelligence tools still use their own higher level languages based upon a multidimensional paradigm. Composable calculations are what is missing from SQL, and we propose a new kind of column, called a measure, that attaches a calculation to a table. Like regular tables, tables with measures are composable and closed when used in queries.
SQL-with-measures has the power, conciseness and reusability of multidimensional languages but retains SQL semantics. Measure invocations can be expanded in place to simple, clear SQL.
To define the evaluation semantics for measures, we introduce context-sensitive expressions (a way to evaluate multidimensional expressions that is consistent with existing SQL semantics), a concept called evaluation context, and several operations for setting and modifying the evaluation context.
A talk at SIGMOD, June 9–15, 2024, Santiago, Chile
Authors: Julian Hyde (Google) and John Fremlin (Google)
https://doi.org/10.1145/3626246.3653374
E-Invoicing Implementation: A Step-by-Step Guide for Saudi Arabian CompaniesQuickdice ERP
Explore the seamless transition to e-invoicing with this comprehensive guide tailored for Saudi Arabian businesses. Navigate the process effortlessly with step-by-step instructions designed to streamline implementation and enhance efficiency.
UI5con 2024 - Boost Your Development Experience with UI5 Tooling ExtensionsPeter Muessig
The UI5 tooling is the development and build tooling of UI5. It is built in a modular and extensible way so that it can be easily extended by your needs. This session will showcase various tooling extensions which can boost your development experience by far so that you can really work offline, transpile your code in your project to use even newer versions of EcmaScript (than 2022 which is supported right now by the UI5 tooling), consume any npm package of your choice in your project, using different kind of proxies, and even stitching UI5 projects during development together to mimic your target environment.
Need for Speed: Removing speed bumps from your Symfony projects ⚡️Łukasz Chruściel
No one wants their application to drag like a car stuck in the slow lane! Yet it’s all too common to encounter bumpy, pothole-filled solutions that slow the speed of any application. Symfony apps are not an exception.
In this talk, I will take you for a spin around the performance racetrack. We’ll explore common pitfalls - those hidden potholes on your application that can cause unexpected slowdowns. Learn how to spot these performance bumps early, and more importantly, how to navigate around them to keep your application running at top speed.
We will focus in particular on tuning your engine at the application level, making the right adjustments to ensure that your system responds like a well-oiled, high-performance race car.
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...XfilesPro
Wondering how X-Sign gained popularity in a quick time span? This eSign functionality of XfilesPro DocuPrime has many advancements to offer for Salesforce users. Explore them now!
4. 4 VictorRentea.ro
a training by
Chapter 1. Concentric Architectures
= Onion, Clean, Hexagonal, Ports-and-Adapters
5. 5 VictorRentea.ro
a training by
IAdapter
Adapter
Onion/Clean Architecture Recap
Outer layers depend on inner layers
Persistence concerns pushed out
Dependency Inversion
(call logic in an outer circle via an interface)
Services + Model
Flow control
(method call direction)
Domain is agnostic to
UI, DB, APIs, Frameworks
(protect the business rules)
Onion Architecture Primer: https://marcoatschaefer.medium.com/onion-architecture-explained-building-maintainable-software-54996ff8e464
7. 7 VictorRentea.ro
a training by
vs interface
Hexagonal aka Port-and-Adapters Architecture
Original Article: https://alistair.cockburn.us/hexagonal-architecture/
Bad cost-benefit
Useless
interface
implements
DepENDENCY INvERSION
Flow control
(method call direction)
8. 9 VictorRentea.ro
a training by
https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/
9. 10 VictorRentea.ro
a training by
Sources of overengineering in Concentric Architectures
Too many interfaces
"any layer must only expose and consume interfaces"
Mandated layers
"a Controller MUST call a Service that MUST call a Repo"
Mock-full tests 🧅
"each layer is tested by mocking the layer below"
Separate Domain from Persistence 😭
"CustomerModel should be mapped CustomerEntity in Repo layer"
Application-layer structures
"Application layer should have its own data structures ≠Domain, ≠Dto"
Rigid dependency management
"domain MUST NEVER depend on anything outside"
Monolithic in nature
"the (one) Domain is in the center"
Are these still problems
in our pragmatic variation?
Delete interfaces with only 1 implementation, unless Dep Inversion
Extract complexity into Domain Services; challenge Controllers
More integration tests (honeycomb) or squash layers
ArchUnit allows exceptions 😬
Only required if UC exposed via 2+ channels
Gulp... 😬 Indeed
Only required if legacy/enemy DB
11. 12 VictorRentea.ro
a training by
Layers
Controller
Repository + Infrastructure
Application Service
Vertical SLICING
DOMAIN Service + Model
Change
12. 13 VictorRentea.ro
a training by
How "wide" should an Application Service be?
= how many use-cases?
Multiple use-cases 👈 what we did
class OrderApplicationService {
public getOrderById() {/*trivial logic🥱*/}
public placeOrder() {..extract..extract...}
// eg. 10 more
}
One class / use-case = Slice by Feature
class GetOrderByIdUseCase{/* 5 useful lines*/}
class PlaceOrderUseCase {/* 400 lines */}
risk: god class
https://jimmybogard.com/vertical-slice-architecture/
continuously extract logic ou
accidental coupling
between use-cases
change 1 use-case=
change 1 (less) files
Group code
by axis of change
13. 14 VictorRentea.ro
a training by
One class / use-case = Slice by Feature
class GetOrderByIdUseCase{/* 5 useful lines*/}
class PlaceOrderUseCase {/* 400 lines */} risk: god classes
https://jimmybogard.com/vertical-slice-architecture/
The stricter the rules are,
the less creative we think
risk: too small classes
risk: repeating logic (DR
extract shared logic to Domain
extract complex logic to Domain
Start Put everything related to a UseCase in a single file,
from Controller down to any custom Repository methods
14. 15 VictorRentea.ro
a training by
One class / use-case = Slice by Feature
class GetOrderByIdUseCase{/* 5 useful lines*/}
class PlaceOrderUseCase {/* 400 lines */}
Query
Command
read data
change data
CQRS
15. 16 VictorRentea.ro
a training by
Encapsulate DTOs
whenever possible
class GetOrderByIdUseCase{ // query 👁
private static class Request { ... } // JSON
private static class Response { ... } // JSON
public Response handle(Request request) {...}
}
class PlaceOrderUseCase { // command ✍️
private static class Request { ... } // JSON
private static class Response { ... } // JSON
public Response handle(Request request) {...}
}
allows different architecture styles per use-case
16. 17 VictorRentea.ro
a training by
Queries 👁
class GetOrderById {
private static class Request { ... }
private static class Response { ....<large>...... }
@GetMapping
public Response handle(Request request) {...}
}
- Can select projections ("select new Dto" JPQL) = different READ Model (CQRS)
- Can use raw SQL, or whatever ...
- If ≥2 Query UC share logic (rarely) extract it (eg. into a Util) = DRY
17. 18 VictorRentea.ro
a training by
Commands ✍️
• Start simple
• Can get veeeery complex. Don't PANIC! Continuously refactor:
Extract Method
Extract Class
Move Methods (into a Domain Model Object or a Domain Service)
class PlaceOrder {
private static class Request { ....<large>.... } // + @NotNull, @Size..
private static class Response { ... }
@PostMapping
@Transactional
public Response handle(@Validated Request request) {
*read stuff*
*interesting domain logic to extract*
*save stuff*
}
}
Perfect Fit for
Task-Based UI
18. 19 VictorRentea.ro
a training by
Layers
Controller
Repository + Infrastructure
Application Service
SLICE BY FEATURE
DOMAIN Service/Model
Logic Shared by 2 Features
extracted into a Domain Service/Model
Complex business logic of a Feature
extracted into a Domain Service/Model
19. 20 VictorRentea.ro
a training by
Application / Infrastructure
Domain
👁 UC-1
External API
✍️UC-3 ✍️UC-4
Domain
Service
Vertical-Slicing vs Concentric Architecture Equivalence
✍️UC-2
Domain
Model
👁 UC-19
👁 UC-17
Not enough domain complexity:
they don't deserve
to be part of Domain
20. 21 VictorRentea.ro
a training by
Microservice (if you must)
Module in a Modulith 👑
Large Slice
Shippin
g
Invoicin
g
Catalo
g
NO: Each Module can decide
how many layers/rings has
its internal structure
Slice by Feature
(aka UseCase, previous slides)
Vertical Slicing Small Slice
What
Size?
No
layers?
= Modular Monolith
21. 22 VictorRentea.ro
a training by
A large codebase is more likely to suffer
from internal coupling (scope creep, domain model dilution),
than external coupling (to external APIs)
24. 25 VictorRentea.ro
a training by
.controller
.service
.repo
.infra
com.myorg.myapp
.order
.product
Too keep packages small,
we grouped classes
in subpackages
Package Names
.entity
.order
.product
ll started with...
technical layers names
(not domain concepts)
25. 26 VictorRentea.ro
a training by
.service
com.myorg.myapp .order
.product .service
The Screaming Architecture
=organize code first by subdomain, not by technical layers
https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html
.entity
.repo
…
…
separate microservices
teams
modules
26. 27 VictorRentea.ro
a training by
Naming
(again)
.order .product
.fulfillment .catalog
.invoice
.invoicing
Group by Business Capability👌
(what it does, its value)
Group by Concept (Data)
28. 29 VictorRentea.ro
a training by
The Fallacy of Nano-Services
• If you break the code in too many modules (eg 20+)
• The local complexity of each piece is ↓ ✅
• But the global complexity gets 🔝 🚫🚫🚫
or Module
https://vladikk.com/2020/04/09/untangling-microservices/
29. 30 VictorRentea.ro
a training by
The Fallacy of Nano-Services
or Module
Local Complexity
how much complexity is
in one microservice/module
Global Complexity
how hard it is to integrate
the microservices/modules
Increase cohesiveness of modules (=break complexity)
while reducing coupling between them (=micro-APIs)
https://vladikk.com/2020/04/09/untangling-microservices/
30. 31 VictorRentea.ro
a training by
A Service is NOT
• Just behavior
Example: calculation, validation
• Just CRUD data
Example: Country, Tenant, Clinic
or Module
Modulith: repos in commons
Microservices: static data or
entity microservice
31. 32 VictorRentea.ro
a training by
A Service is ...
the technical authority for a business capability
or Module
.invoice .invoicing
32. 33 VictorRentea.ro
a training by
Cognitive🧅 Load: able to specialize in one area
Code Ownership & Control: free to refactor the Domain Model
Bounded Contexts: sharp concepts, less attributes & more constraints
Ideally 1 module = 1 Team = Two-Pizza Team
Align with Organization Boundaries (stakeholders) - Conway's Law
Has a sound responsibility ?
Finding Module Boundaries🏆
Changing its internal structures and business rules affects other modules?
Its API changes when other modules change? (=coupling)
Is it replaceable with off-the-shelf software?
Is it easy to remove when the business need is gone?
Is it testable alone, ie without creating many entities from other modules?
36. 40 VictorRentea.ro
a training by
What's faster to build?
(from scratch)
Microservices
A Monolith or
But soon complexity and
coupling
start slowing us down
37. 41 VictorRentea.ro
a training by
41
From a Big Ball of Mud Microservices
1) Rewrite (big-bang)
No new features for 1 year
Requires re-specifying everything
20-30% success chance (studies)
2) Modularize => Extract
Experiment and prototype
Be ready to stop any time
3) Strangler-Fig Pattern
Reimplement any all features
in fresh microservices
👑
Modulith
38. 42 VictorRentea.ro
a training by
A new greenfield project
Proxy
The Strangler Fig Pattern
😁
When a feature is
reimplemented,
route the requests for it
to the new project
Prerequisite: clear requirements
39. 43 VictorRentea.ro
a training by
order
product
Unlink Domain Entities
class OrderLine {
...
Product product;
Long productId;1
String productName;2
}
class Product {
id
name
...
}
1) Keep only the ID ✅
👌 Preserve the FK in Modulith
+ then later: fetch on-demand
2) Snapshot immutable data
+ according to domain rules
3) Keep mutable data in sync 😨
+ replicate changes (eg via events)
⚠️Eventual Consistency (iff distributed)
object
reference
40. 44 VictorRentea.ro
a training by
complexity
complexity
booking appointment
Split Domain Entities
class BookingRequest {
id
date + time
specialtyId
...
}
class Appointment {
id
medical report
followup date
date + time
...
}
class Appointment {
id
date + time
specialtyId
... +20 fields
appointed:boolean
medical report
followup date
... 40 more
}
41. 45 VictorRentea.ro
a training by
👌
The owner of some data
is the module who changes it
The modules that need the data must ask the owner
42. 46 VictorRentea.ro
a training by
0 Writers | * Readers = Reference Data 'shared' module
- eg. Country list
1 Writer | n Readers = Owned Readers get data from Writer
- eg. Catalog Stock.getStock()
n Writers | 0 Readers = Notifications commons via events
- eg. Audit, sendSMS
2+ Writers | * Readers Split Entity 😩 or Merge modules ❤️
- eg. break Order PlacedOrder + ShippedOrder
Data Ownership
# modules
43. 48 VictorRentea.ro
a training by
Calls between Modules
module
A
module
B
call any class inside B
Lack of
encapsulation
External API
(eg HTTP, gRPC,...)
dev riot
Why so many
structures?!!😡
Goal = Decoupling
- Review the coupling
- Detect cyclic dependencies
- Detect "Module in the middle"
DTO
Internal API
("Door")
DDO
Data Decoupling Objects
calls only via B's "Door"
44. 49 VictorRentea.ro
a training by
Cyclic Dependencies between Modules
A B
call
call
Bad news: Maven/Gradle build fails
<dependency>
<dependency>
45. 50 VictorRentea.ro
a training by
Ways to fix Cyclic Dependencies between Modules
Key Questions:
- massive interdependence?
- need to reuse technical/infra stuff?
- any existing monolithical clients / frozen API?
- are modules exposing external APIs?
46. 51 VictorRentea.ro
a training by
A B
A-api B-api
Extract API modules
No single orchestrator
runtime calls
A B
O
orchestrator
Keep Orchestration Up
= Facade
(eg site?, mobile)
Ways to fix Cyclic Dependencies between Modules
A B
event
call
Fire Events Upstream
⭐️Decoupled
A B
implements
call
Dependency Inversion
⭐️Decoupled
AProvider
AProviderImpl
call
microservices: N/A
microservices: events on queue
microservices: interdependent microservices
microservices: api gateway/saga microservices: shared lib/3rd service microservices: merge?
A B
C
commons
Push Commons Down
Technical:
emails
country
audit, ...
❤️
AB
Merge Modules
if tight
coupling
47. 52 VictorRentea.ro
a training by
B
Surface of a Module
publish events
call
interface
implementation
A
command
(change)
query (read)
(a) notification {id}
(b) fat-event {data}
listen to events
48. 53 VictorRentea.ro
a training by
Segregate in baby-steps
Prepare to stop/undo when needed - incorrect boundary?
Too many tiny modules will 🔝 the Global Complexity
Focus on Data ownership & Flow control
Introduce Events for one-way signals, w/o response
Do NOT sacrifice consistency too early (Transactions, FKs)
Measure progress (eg. ArchUnit, custom tool)
Modulith Lessons
51. 56 VictorRentea.ro
a training by
Reasons to extract a Module into a Microservice
• Different Resource Requirements (eg NOSQL vs RDB)
• Scalability, or go Reactive🔥
• Availability (not impacted by failures in other modules)
• Requires different programming language / exotic framework
• High rate of delivery => independent deployability
• Security posture (vs Wild Wild Web)
• 🛑 STOP if Strong Consistency Requirements: terrible business consequences
• ...
52. 57 VictorRentea.ro
a training by
Module or Microservice?
https://www.confluent.io/resources/event-driven-microservices/
53. 59 VictorRentea.ro
a training by
4) Distributed Systems
1) code decoupling 3) ❌ DB Consistency
2) ❌ Transactions
A
B
A
B
Shared
Transaction
TX
method calls and events
only via doors ✅
External REST API
Foreign Key
Data Replication
(events, CDC, ...)
🔥
MICROSERVICES
🔥
- retry
- idempotency
- queues
- load balancing
- 503
- Network Delay
- k8s, Docker
- rate limiter
- distrib. cache
- circuit breaker
- 😱😱😱😱
TX
>@TransactionEventListener(AFTER_COMMIT)
>@Async @EventListener (worse!)
Tx not shared between modules ✅ Separate Schemas ✅
😱 😱 😱 Eventual Consistency 😱 😱 😱 => Questions to BIZ
Monolith => Modulith => Microservices
Blue Team 👕
Pink Team👚
Partially inspired by Axel Fontaine's talk about the "Majestic Modular Monolith": https://www.youtube.com/watch?v=vV34-3NZkh4
54. VictorRentea.ro
60
Final poll, what architecture have you used by now?
A) Layers: 13/
B) Onion (domain module) 6/
C) Port-adapters (*Port) 4/
D) Feature Slices (*UseCase) 5/
E) Modulith (functional modules in a monolith) 10/
F) Event Sourcing + CQRS 4/
(Total answers: 16/)
55. 61 VictorRentea.ro
a training by
📚
Hexagonal Architecture aka. Ports-and-Adapters
- Original article by Alistair Cockburn, 2005: https://alistair.cockburn.us/hexagonal-architecture/
- Colorful explanation, 8th light: https://8thlight.com/insights/a-color-coded-guide-to-ports-and-adapters
- Input Port Interface are useless: https://softwareengineering.stackexchange.com/q/438705
Onion Architecture
- Clean Architecture Uncle Bob: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
- Onion Architecture Primer: https://marcoatschaefer.medium.com/onion-architecture-explained-building-maintainable-software-54996ff8e464
- Original article, Jeffrey Palermo, https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/
Vertical Slice Architecture (aka -UseCase)
- Feature slicing Jimmy Bogard talk: https://youtu.be/5kOzZz2vj2o and short intro article: https://jimmybogard.com/vertical-slice-architecture/
- Task-based UI: https://cqrs.wordpress.com/documents/task-based-ui/
Finding Module/Service Boundaries
- Heuristics to find boundaries: https://www.dddheuristics.com/design-heuristics/
- Organize by features, not by entities, Adam Ralph: https://youtu.be/tVnIUZbsxWI
Modular Monoliths
- Majestic Modular Monolith, Axel Fontaine: https://youtu.be/BOvxJaklcr0
- Local Complexity vs Global Complexity in microservices: https://vladikk.com/2020/04/09/untangling-microservices/
Comparisons:
- Comparison of Layered, Onion, vs Vertical Slices, Simon Brown: https://youtu.be/5OjqD-ow8GE
- Nice overview + picture ⭐️ https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/
Task-based UI:
- https://codeopinion.com/decomposing-crud-to-a-task-based-ui/
Books:
- Software Architecture: Fundamentals & The Hard Parts by Neal Ford & Mark Richardson
Architecture Reading
Hinweis der Redaktion
Salut! Eu sunt Victor si am 14 ani… de lucru cu Java, desi in ultimii ani am fost impins sa invat si PHP, Scala si C#.
Lucrez la IBM ca Lead Archirect, in Bucuresti. Stiati voi ca aveti un IBM chiar aici in Cluj, intr-un sediu nou-nout. In….
De fapt, cu ajorul IBM sunt astazi aici cu voi.
Stiu deja ce ganditi… aa.. E architect. Sta undeva langa un ficus si deseneaza pe pereti diagrame UML..
-NU . Eu bag la cod. Lucrez pe cele mai dificile proiecte pe care le avem.
La sfarsh:Sala mare -