Three Dots Labs·1yLearning Software Skills fast: what worked for us best in the last 15 years
Learning as a software engineer can be enhanced by focusing on practical application of knowledge, building challenging real-life projects, embracing frustration during the learning process, and concentrating on timeless concepts rather than framework-specific details. Combining theory with practice incrementally is crucial for effective learning.
Awesome Go·49wMVC vs DDD: Go Language Architecture Deep Dive
Compares MVC and DDD architectural patterns for Go applications, examining their structural differences, code organization approaches, and use cases. MVC organizes code by technical layers (Controller/Service/Repository) and suits smaller systems with stable requirements, while DDD structures code around business domains with four layers (Interface/Application/Domain/Infrastructure) and better handles complex business logic. The guide provides detailed directory structures, code examples, and implementation best practices for both patterns in Go, highlighting that MVC offers simplicity and rapid development while DDD provides better scalability and maintainability for complex systems.
Awesome Go·50wModern (Go) application design
Explores modern Go application design principles emphasizing structure and composability. Discusses two key approaches: use case-driven structure (like CLI tools) and data model-first principles using repository patterns with generics. Demonstrates how to separate concerns through layered architecture with storage, business, and view layers. Shows practical examples of implementing CRUD operations, aggregates, and the MVC pattern while maintaining clean boundaries between components for better testability and maintainability.
Jobs·41wDomain Driven Design: Key Concepts and Practical Approach
Domain Driven Design is not about creating domain folders but about modeling code around business responsibilities with clear subdomain boundaries. Each subdomain should handle its own responsibilities and communicate through well-defined interfaces, creating parent-child relationships where domains collaborate through contracts rather than direct dependencies. The approach emphasizes balancing abstraction with practicality, distinguishing between library code (heavily abstracted for reuse) and domain code (tied to specific business contexts).
Microservices.io·34wA must-read book - Architecture for Flow: Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies
A recommendation for Susanne Kaiser's book that combines Domain-Driven Design, Wardley Mapping, and Team Topologies to build adaptive systems. The book addresses how IT organizations can adapt quickly in volatile business environments by applying these three methodologies together to achieve fast flow and organizational agility.
swizec.com·49wWhy utils are bad, an example
Utils-based code organization creates circular import problems that break applications unexpectedly. When payment utils depend on email utils and vice versa, Python cannot resolve the circular dependencies. The solution is vertical module organization based on domain context rather than technical function - group everything about payments (including emails) in a payment module, while keeping low-level operations like email sending in separate atomic libraries.
Three Dots Labs·24wDDD: A Toolbox, Not a Religion
Domain-Driven Design (DDD) should be treated as a flexible toolbox rather than an all-or-nothing methodology. Most software projects fail due to poor handling of business domain complexity, not technical challenges. The core principle is understanding and modeling the business domain well in code, with strategic patterns (like bounded contexts and core domains) being universally valuable, while tactical patterns should only be applied when they solve actual problems. Developers often over-focus on technical complexity and frameworks instead of domain understanding, leading to legacy code. The key is pragmatically selecting DDD patterns that address real issues in your specific context, avoiding both religious adherence and complete dismissal of the approach.
freeCodeCamp·37wHow to Extend CRUD Operations to Align with Business Workflows
CRUD operations work well for simple applications but become problematic at scale when business workflows require domain-specific actions. Instead of generic create, read, update, delete operations, APIs should model actual business processes like submit, approve, reject, and withdraw. This approach improves authorization, auditability, and workflow enforcement while making the system's intent clearer and reducing security risks.
Three Dots Labs·23wHow to Know If your Software Is Overcomplicated or Oversimplified?
Software complexity stems from two extremes: overengineering with unnecessary patterns and oversimplifying complex domains. Essential complexity is inherent to the domain and unavoidable, while accidental complexity comes from poor implementation choices. Simply saying 'keep it simple' is insufficient—achieving simplicity requires deliberate effort and matching architectural patterns to actual problem complexity. Red flags include inability to deploy daily, fear of making changes, and team dissatisfaction. The solution involves using defensive programming, avoiding dogmatic approaches, mixing simple and sophisticated patterns appropriately, and focusing on shipping fast with incremental changes rather than premature optimization.
ITNEXT·51wAbstractions Done Right: Discussing When It Is Worth Or Not
Abstractions like interfaces and layered architectures are valuable when used correctly, not just for replacing implementations but for deferring decisions and isolating concerns. The author advocates for a 4-layer approach (UI, Application, Domain, Infrastructure) that enables vertical development and reduces cognitive load. Two real-world examples demonstrate when abstractions provide clear value (migrating from serverless to Kubernetes) versus when they create unnecessary overhead (simple Step Function tasks). The key is understanding that abstractions' main benefit is enabling focused development and clearer intent, with implementation flexibility as a bonus.
API Evangelist·32wApplying Domain-Driven Driven Design to Integration and Consumption
Explores applying domain-driven design principles to API consumption and integration, not just production. Discusses how concepts like bounded contexts, ubiquitous language, and aggregates help API consumers manage third-party services by establishing control over how multiple APIs work together, even when individual API designs are outside their control. Challenges the notion that DDD only applies to API producers.
ByteByteGo·40wEP176: How Does SSO Work?
Single Sign-On (SSO) enables users to access multiple applications with one login through Identity Providers and Service Providers. The newsletter covers API design best practices including clear naming, idempotency, pagination, and security. Domain-Driven Design concepts are explained including Entities, Value Objects, and Aggregates. Popular AI agent frameworks like LangChain, AutoGen, and CrewAI are compared for building intelligent systems. OpenAI's new open-source GPT-OSS models use Mixture-of-Experts architecture with specialized neural networks for efficient processing.
Architecture Weekly·39wMy thoughts on Vertical Slices, CQRS, Semantic Diffusion and other fancy words
Explores the relationship between Vertical Slice Architecture (VSA) and CQRS, arguing that VSA is essentially CQRS with more prescriptive organizational guidance. Discusses two main approaches to implementing vertical slices: pure self-contained slices versus slices with thin coordination layers. Addresses how semantic diffusion corrupts architectural patterns over time, turning simple concepts like CQRS and VSA into complex, misunderstood implementations with unnecessary constraints. Emphasizes that both patterns work well for simple CRUD systems and can evolve as complexity grows.
Telerik·50wDomain-Driven Design Principles: Value Objects in ASP.NET Core
Value objects are immutable entities in domain-driven design that lack identity and are recognized by their values rather than unique identifiers. The article demonstrates implementing value objects in ASP.NET Core through a practical Address example, covering the creation of a base ValueObject class with equality comparison methods, proper Entity Framework Core configuration for non-entity objects, and the benefits of using value objects for domain expressiveness, immutability, and separation of concerns in software architecture.
Milan Jovanović·1yFrom Anemic Models to Behavior-Driven Models: A Practical DDD Refactor in C#
The post explores the transformation of anemic domain models into behavior-rich aggregates through incremental refactoring, with a focus on enhancing code maintainability and clarity of business rules in legacy C# codebases. It highlights the methodical steps to embed business logic inside the domain, improving encapsulation and reducing coupling in the application service layer.
