How We Implemented Domain-Driven Development in Golang

Summary

Building GrabPlatform's partner integration self-service portal initially resulted in an unstructured codebase where individual files exceeded 500 lines and lacked proper segregation. Modifying existing functions carried high risks of breaking functionality across imported source collections. To resolve this, the team restructured the Go application using Domain-Driven Design principles in coordination with product domain experts. They mapped business rules into bounded contexts, identified entities and aggregate roots, introduced repository interfaces, and utilized domain events for cross-context communication. The refactoring distributed core functionality evenly, simplified onboarding, and aligned technical terminology with business concepts.

Takeaways

1. 1

   Project serves as an aggregate root because dependent mapping entities like DeveloperProjectDAO and ProductProjectDAO cannot exist without it.

2. 2

   Domain events allow bounded contexts to propagate updates and fetch full domain attributes without creating direct entity dependencies.

3. 3

   Starting with database schemas rather than domain expert collaboration risks producing an anemic domain model based on relational data rather than business functionality.