DanielHinojosa
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.
Join us for an indepth exploration of cuttingedge messaging styles in your large domain.
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 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?
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 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.
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?
Zero fluff.