Elevating Software Quality and Value Creation with Domain Driven Design + Hexagonal Architecture

Here at Shrine we pride ourselves on being value-driven developers and thus we are not impressed by shiny new frameworks or tech. Our focus is on patterns and tools that can 10x the value creation to our clients. One design pattern that we’ve been using and experiencing this 10x improvement is the merge of Domain Driven Design (DDD) with Hexagonal Architecture.

Here are a couple of those improvement areas and why they happen:

Code readability and developer experience

As business logic is kept at the center of the application and we abstract away all implementation details like databases, communication protocols or external services, even a non-tech person can navigate the code and understand the business logic implemented.

New developers onboarding to a codebase to extend and modify a feature can easily identify the touch points needed as they are centralized in the domain layer and written in plain english. This self documenting aspect of our codebases is also called Screaming Architecture because what the software is supposed to do stands out in your face.

Code maintainability and extensibility

As codebases grow and business requirements evolve, so does the software complexity and there is no way around it. The problem is that in most codebases, complexity increases exponentially, which leads to an ever growing time to market for new features. By keeping the business logic at the center of the application and creating clear boundaries between your domains, we can make the complexity increase closer to linear.

This can be especially important in bigger organizations with various stakeholders with power to influence your product. We’ve seen really simple features evolve to a complex business logic during development as new stakeholders were added to conversations and we were able to accommodate these new requirements and complexity without impacting the timeline or creating tech debts.

Code testability and confidence on 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.

—

In conclusion, the combination of Domain Driven Design (DDD) and Hexagonal Architecture has proven to be a powerful approach here at Shrine, significantly improving code readability, maintainability, extensibility, and testability. This design pattern totally aligns with our value-driven development ethos, enabling us to deliver high-quality software that meets evolving business needs and maximizes value for our clients.

ps. this is the original version from this Shrine Blog Post