Daniel is a programmer, consultant, instructor, speaker, and recent author. With over 20 years of experience, he does work for private, educational, and government institutions. He is also currently a speaker for No Fluff Just Stuff tour. Daniel loves JVM languages like Java, Groovy, and Scala; but also dabbles with non JVM languages like Haskell, Ruby, Python, LISP, C, C++. He is an avid Pomodoro Technique Practitioner and makes every attempt to learn a new programming language every year. For downtime, he enjoys reading, swimming, Legos, football, and barbecuing.
Event-driven architecture (EDA) is a design principle in which the flow of a system’s operations is driven by the occurrence of events instead of direct communication between services or components. There are many reasons why EDA is a standard architecture for many moderate to large companies. It offers a history of events with the ability to rewind the ability to perform real-time data processing in a scalable and fault-tolerant way. It provides real-time extract-transform-load (ETL) capabilities to have near-instantaneous processing. EDA can be used with microservice architectures as the communication channel or any other architecture. In this workshop, we will discuss the prevalent principles regarding EDA, and you will gain hands-on experience performing and running standard techniques.
This presentation will discuss the patterns required when things go wrong in architecture and how to stay resilient under pressure. These are battle-tested patterns that every architect should know.
In this session, we will discuss architectural concerns regarding security. How do microservices communicate with one another securely? What are some of the checklist items that you need?
We take a look at another facet of architectural design, and that is how we develop and maintain transactions in architecture. Here we will discuss some common patterns for transactions
This workshop will explore the principles of the Ports and Adapters pattern (also called the Hexagonal Architecture) and demonstrate how to refactor legacy code or design new systems using this approach. You’ll learn how to organize your domain logic and move UI and infrastructure code into appropriate places within the architecture. The session will also cover practical refactoring techniques using IntelliJ and how to apply Domain Driven Design (DDD) principles to ensure your system is scalable, maintainable, and well-structured.
This workshop will explore the principles of the Ports and Adapters pattern (also called the Hexagonal Architecture) and demonstrate how to refactor legacy code or design new systems using this approach. You’ll learn how to organize your domain logic and move UI and infrastructure code into appropriate places within the architecture. The session will also cover practical refactoring techniques using IntelliJ and how to apply Domain Driven Design (DDD) principles to ensure your system is scalable, maintainable, and well-structured.
This session will focus on data governance and making data available within your enterprise. Who owns the data, how do we obtain the data, and what does governance look like?
Join us for an indepth exploration of cuttingedge messaging styles in your large domain.
Domain Driven Design has been guiding large development projects since 2003, when the seminal book by Eric Evans came out. Domain Driven Design is split up into two parts: Strategic and Tactical. One of the issues is that the Strategic part becomes so involved and intense that we lose focus on implementing these sorts of things. This presentation swaps this focus as topic pairs. For example, when we create a bounded context, is that a microservice or part of the subdomain? When we create a domain event, what does that eventually become? How do other tactical patterns fit into what we decide in the strategic phase?
Domain Driven Design has been guiding large development projects since 2003, when the seminal book by Eric Evans came out. Domain Driven Design is split up into two parts: Strategic and Tactical. One of the issues is that the Strategic part becomes so involved and intense that we lose focus on implementing these sorts of things. This presentation swaps this focus as topic pairs. For example, when we create a bounded context, is that a microservice or part of the subdomain? When we create a domain event, what does that eventually become? How do other tactical patterns fit into what we decide in the strategic phase?