Clean Architecture Stream Recap, Part Two This Week, Newsletter Update
In case you missed it!
Newsletter update: One of the daily posts every week from now on will be devoted to summarising my streams, public discussions and open coaching group conversations. There’s a lot going on and I want to give you a simple go-to place where you can calmly check what’s been happening.
This way you can simply determine if you missed anything that interests you. Here’s my public schedule of recurring activities:
Live Stream—Every week on Thursdays 16:30 CEST on YouTube and LinkedIn.
Book Club—Every month, starting with the first full week. Private meetings are also on Thursdays at 17:30 CEST. This month we are reading The Fearless Organization. Next month is Implementing Lean Software Development.
This THU: Dependency Injection with Clean Architecture (YouTube / LinkedIn)
This is the upcoming stream 👆
This is last week’s stream 👇
Key Insights from last week
💡 The domain layer should be the termination point of the dependency graph, with cohesive coupling only within itself and avoiding dependencies on the application and infrastructure layers.
🧱 The framework does not have your best interest in mind. There's no incentive for the framework author to optimize for your business. They can’t know about your business. So they optimise for adoption. The framework is capturing intent by being generic. Your business is capturing market share by being unique.
💡 Abstracting the database significantly improves the speed of running tests. The intention isn’t to speculatively prepare your app to swap from MySQL to Postgres. It is to keep your test-bed running fast. The speed of the test suite is a key predictor of productivity in a fast paced, high performing team.
🤔 Clean architecture is difficult because it requires understanding the business intent and inverting the layers accordingly, rather than simply following an ideal folder structure or project setup.
🔄 Do not create the perfect system on day one. Clean Architecture and DDD are about continually refactoring and distilling domain models following market validation and market demand. You will start with a big ball of mud. That’s fine. Clean Architecture is a possible output of what you do with that mud.
⚖️ Quality is the result—the output— of iterating on the team, increasing market fit, distilling and re-modelling the domain (DDD) and refactoring code. Creating a win-win situation for the product engineering team and the business.
📈 The architecture should match the level of technical excellence that the business requires, ensuring that it meets the needs of the business.
Questions Answered
Q: “Controversial: Is the database really a detail?“
🎥 [10:00] - Great question, thank you Milan!
Q: “Is there any difference between port and adapter?“
🎥 [17:00] - Definitely strong Hexagonal Architecture vibes! I recommend following Valentina Cupać for a more expert opinion on this topic:
Q: “Should a domain class encapsulate a repository inside?“
🎥 [23:17] - Classic ADO db approach. We all used it, your mileage may vary.
S[tatement]: “Sometimes we confuse the database with the data.“
🎥 [36:11] - This is a typical question on traditional vs. event sourced systems. Can’t wait for our podcast, Tyler!
Q: “What type of application can we classify as ‘Simple’?“
🎥 [42:10] - Simple is usually the output of an expensive, mature process. One doesn’t start simple.
Q: “Is the repository an abstraction between your data and the detail that is your database? Is it the place where you inject infrastructure […]?“
🎥 [52:48] - Love this detail! Abstractions everywhere, but what are we abstracting?
S: “We have DDD repositories and framework repositories.“
🎥 [57:46] - Common mistake for beginners.
Q: “How do we plan reusability if we slice vertically?“
🎥 [01:01:32] - I’m a big fan of Vertical Slice Architecture and Use Cases.