Announcement: Tune in for Event Modeling with Clean Architecture
This week's Live Stream - August 17th, 2023 / 16:30 CEST
We continue our live stream theme of Clean Architecture. Last week we explored Dependency Injection in the context of Clean Architecture along with a course review.
This week we explore how Event Modeling can help you shape your understanding of building event-driven and event sourced applications in Clean Architecture style. Live discussions, Q&A and course review.
Call for feedback - How are you liking the chat participation on Linkedin? Is the Event for each week easy to find?
👇 Sign up on the LinkedIn event to have it easily pop into your calendar.
Agenda for the Live Stream
Event Modeling Cheat Sheet
#eventmodeling community moving to discord
Reviewing confluent.io course Practical Event Modeling by Bobby Calderwood
Discussion & Q&A
Event Modeling
Like many others, you are likely somewhat familiar with Clean Architecture but event modeling is new to you. That’s fine!
No worries if you missed it, here’s last week’s recap
🤔 Dependency injection is a recommended practice for applying clean architecture, and without it, implementing clean architecture can be challenging. We looked at the video below by CodeAesthetic 👇
🔄 Dependency injection allows for flexibility by allowing different implementations of an interface to be injected, allows for separation of generic domain-level concerns from specific and mutually exclusive infrastructure-level concerns.
🎯 Milan's attention to detail and care in creating the course is evident, ensuring that it delivers a beautiful learning experience. The course provides detailed guidance on implementing clean architecture in a C# environment, covering topics such as domain factory patterns, mediator configuration, and the use of secure connections.
💡Clean architecture is not something to strive for as a skill, but rather an outcome of good craftsmanship practices that provide value to the business. You start with the big ball of mud that provides business value, and continuously clean it. The output is CA.
🔥 Nullable types are often a sign of shotgun surgery or refused bequest. Having a type that serves an if-statement of branches A or B with uniquely separate data for each branch will be fully nullable. Maybe-defined is not the same as always defined on branch A and never defined on branch B. This is a sign of code smells downstream of the usage.
🧠 Separating the delivery mechanism from the business logic in clean architecture helps in encapsulating and representing the business logic, making it easier to maintain and modify.
💡Domain-driven design should be mandatory before starting programming, as it helps programmers understand how their skills benefit the business.
🏛️ Clean architecture serves as a termination rule when developers are unsure about where to place certain elements, providing a clear separation between the domain and application layers. This is crucial to unstuck yourself from passion-refactoring in circles endlessly.
💡Clean architecture should not be the first priority, but rather an output of continuously refactoring and applying solid principles and good design practices to the entire system architecture.
#3 Recap - Questions Answered
Q: “If someone asked me in an interview what is Clean Architecture in general what should I say?”
🎥 [7:34] - It’s okay not to know what CA is. You can always mention the roots: the architectural style mentioned in the book Clean Architecture, building upon similar layered approaches.
C: “It [Clean Architecture] is a design pattern that allows the business logic to be separated from its delivery mechanism. Think of concentric circles with the app logic in the center and everything that supports interaction with other systems, including UI, as adapters or ports.“
🎥 [9:38] - Wouldn’t directly call it a pattern. It’s more like a principle, a goal, a benchmark. Certainly healthy overlap with hexagonal and vertical-slice architecture.
Q: “If I need to use some library in my business logic, is it ok if my Domain layer depends on that specific library?“
🎥 [11:20] - 3rd-party APIs are 99% of the time infrastructure concerns. Only when the library is crafted for your domain, for your business it belongs more naturally into the inner circles.
Q: “As a senior software engineer, do you think someone really needs to have in-depth knowledge of concepts like Clean Architecture, Onion Architecture, Hexagonal Architecture, Monolithic Architecture, Microservices, Modular Monolithic, DDD etc, etc.? What are your thoughts on this?“
🎥 [13:05] - Simply: no on architecture—though don’t avoid them on purpose— definite yes on Domain-Driven Design. We are solving problems, not selling architecture or engineering—selling code is the domain of low-code no-code solution platforms.
Q: “What do you think about vertical slice arch in CA?“
🎥 [56:57] - It’s a great bonus property, but don’t force it onto legacy systems without good cause. There don’t seem to be any short-term benefits. VSA is definitely secondary to having clear modules and business understanding.
Q: “While the course [Pragmatic Clean Architecture] uses C# for illustrations, I'm assuming the knowledge is transferable to other languages+frameworks?“
🎥 [1:00:54] - Very easy to follow. Useful if you want to learn a bit of C# to follow as you go. However the C# code examples are a staple foundation of this course, so your experience may vary if you are consciously avoiding the practical sides.
Q: “For someone transitioning from engineering to a cto role, would clean architecture skills help? This question is from a small startup scale perspective. What other skills besides engineer should one work upon?“
🎥 [1:01:50] - Clean Architecture is very important, but only if the team is already on board. If they want to apply CA, don’t get in their way. Mandating it however, will not produce any positive outcomes as they might be other fundamentals lacking: CI/CD pipeline, code smells, refactoring focus.
Q: “Would you use this architecture in a project where infrastructure layer which includes data access logic in F# (via direct SQL type providers) is used?“
🎥 [1:04:55] - Great question! From what I understand Type Providers are closer to DTOs and VO’s rather than full-on domain concepts. However, while DTOs are fine as a primitive, VO’s should be domain aggregate-specific. When the database itself contains important compute and domain invariants then you can flip the layers, and treat it like a domain concept. When used as storage mechanism, it is infrastructure. However, careful when the app is a hybrid of both. You may need inversion and good separation.