🔴 Pull requests & mono-tasking — Engineering Culture Stream
This week's Guest, Agenda & Recap of last week
Last call on the TDD survey - The survey is closing Friday.
👇 Note: Starting 30 minutes sooner this week, at 16:00 CEST. Sign up on the LinkedIn event to have it easily pop into your calendar. It will be recorded, but I suggest you join in live for the chat participation.
Please set an intention if you don’t want to miss it. Let us know you’re coming and put it on your calendar.
Agenda for the Live Stream
Healthy engineering culture
The problems with Pull Requests
Mono-tasking
Q&A, live discussion throughout the 90 minutes. Don't be shy!
Check your time: Some countries will start rolling daylight saving changes starting next week. The event local follows Paris/Berlin/Amsterdam time.
Adrian’s Teaser 👇
Last week’s DDD / CA recap with
Software architecture and development best practices
💡 The idea of having a prescriptive approach to development can be beneficial for teams, as it eliminates the need for repetitive and slightly different setups for each microservice, streamlining the deployment process.
🏢 Bad architecture in large companies can lead to developers creating their own solutions, such as spinning up microservices, as a form of rebellion against prescription, resulting in a messy and inconsistent project structure.
🤔 Milan suggested organizing the code structure based on features, where the presence of a "get" in the feature name indicates a query and the absence indicates a command that updates the database. This serves the need for clear and consistent naming conventions when organizing code, highlighting the importance of readability and maintainability.
🌐 Clean architecture aims to distill technical concerns and express the needs of the current business, aligning technical decisions with the specific requirements of the business problem.
🤔 Don't become a stressed out introvert when facing a problem you haven't solved before; instead, embrace the opportunity to showcase your problem-solving approach and willingness to learn.
Course: Confidently Ship Production-Ready Apps Using Clean Architecture
Crafting Tech Teams is an affiliate for the course above. Use the code DENIS for 10% off! Thank you for the sponsorship, Milan 🤝
Domain-driven design principles and practices
💡 One of the core ideas in domain-driven design is to create a language that represents the specific domain being worked on, using jargon and terminology that is specific to that domain.
🌐 The example of having separate Amazon accounts for different regions highlights the possibility of having different states and orders associated with the same email in different databases, showcasing the flexibility and scalability of not strictly enforcing email uniqueness.
🌍 Domain-driven design acknowledges the messy and asynchronous nature of the real world, and encourages modeling it in software systems.
🧠 In DDD all invariants are still correct after a command has run, such as ensuring that an email is unique before allowing a user to log in. This doesn’t mean infrastructure logging needs to be consistent. What should be consistent is the Domain communicating whether invariants are upheld or not. However, invariants should always be enforced—so the desire to want looser invariants is a signal for refactoring or remodelling.
🧩 Aggregates in domain-driven design are primarily used to encapsulate invariants, such as unique constraints, that cannot be enforced through the infrastructure layer.
 | A guest post by
|