At Shrine, we pride ourselves on being value-driven developers. So, we are not necessarily impressed by shiny new frameworks or tech trends. Rather, we opt for proven patterns and tools that can provide significant value creation for our clients. One design pattern that has demonstrated a 10x improvement in value creation for our clients is the merging of Domain-Driven Design (DDD) with Hexagonal Architecture.  Â
Domain-Driven Design with Hexagonal Architecture boasts intuitive features that streamline the development process. There are many advantages of incorporating DDD and Hexagonal Architecture into a software build. Here are three highlights.
- Code readability and improved developer experience. With business logic kept at the center of the application, even a non-tech person can navigate the code and understand the business logic implemented. New developers onboarding to a codebase can easily identify the touch points needed to extend and modify a feature, given they are centralized in the domain layer and written in plain English. This self-documenting aspect of the codebases is called Screaming Architecture, since the purpose and intent of the software is clear and right in your face.
- Code maintainability and extensibility. As codebases grow and business requirements evolve, so does the software complexity. There is no way around it. The issue is that in most codebases, complexity increases exponentially. This leads to a longer time to market for building out new features. However, by keeping the business logic at the center of the application and creating clear boundaries between domains, we can make the complexity increase closer to linear. This can be especially important in bigger organizations that have various stakeholders with power to influence the product. We’ve seen simple features evolve into complex business logic during development as new stakeholders become added to conversations. Yet, thanks to DDD and Hexagonal Architecture, we were able to accommodate these new requirements and complexity without impacting the timeline or creating tech debts.
- Code testability for new releases. It’s truly a joy to write tests on codebases with this pattern because you’re able to test 90% of your business logic with simple unit tests. Those high value unit tests run in an instant, which allows the developer to enjoy a real time feedback cycle between his code and his tests.The psychological aspect of having fast running tests that actually provide confidence when extending the codebase is super important. If testing is painful, doesn’t provide confidence and the pressure for delivery is high, even high integrity good developers will create dumb tests just to pass a coverage check. By writing domain/business logic centric code you also end up helping your AI assistant better contribute with suggestions for your tests.
