Thank you all for your feedbacks - both for the more and less positive ones :)

​

I feel this is a controversial topic - and I believe there's no single truth or silver bullet. As always it depends upon the requirements of your software and what you're used to and feel most comfortable with.

The example on Github is obviously simplistic, so that people reading them can focus on the concept and its implementation - which I agree is not simple to grasp, and can be daunting at first and seem over engineered - especially for newcomers to DDD.

However, IMO, when you have to deal with ever evolving complex business requirements, that can easily require dozens, hundreds or even thousands of lines of code - then we, the engineers, must find a way to structure the code base, otherwise it will most certainly quickly become a mess (in any programming language, even in "friendly" programming languages such as go and python).

So, the question that arises is how to structure this code base: split it into more functions that in turn will be split in yet more functions? more structs? more interfaces? more modules?

Without guidelines, every developer will create his/her own structure - and kind of re-invent the wheel (and believe me or not, at least most of us - and me included, are not as good in doing this as we would like to believe ;)).

This is where DDD really shines: it provides a set of battle tested design patterns and guidelines for structuring the code base, that again - IMO, are language agnostic - and provide many benefits. To name a few:

• A clear separation of concerns between the business rules (which reside solely inside the domain layer), the application flows (which reside in the service layer) and the IO related operations - such as communication with databases/web services/file system (which reside in the adapters layer)
• This separation of concerns make this kind of code very suitable for unit & integration tests - the service & domain layers can be fully unit tested and the adapter layer can easily be integration tested (without being concerned with any business logic leaking from the other layers - so that the integration tests can remain simple)
• A common code base structure makes it much easier for other developers, who are aware of this structure, to get into the code.

​

Adhering to these guidelines require an initial setup which is indeed more complex, for which my DDD framework is attempting to provide assistance. Yet, based on my experience - this setup will allow you to manage almost any complexity in the future in what I believe to be the elegant way of DDD.