Comment by pinoy420
9 months ago
In typical HN commenter smugness. It took me less than that to realise it was bullshit. It didn’t make things clear, it made them more abstract and more resistive to change. Similarly with DDD. Just build what you need and deal with the consequences of inevitable change later. No one cares if you miraculously perfectly modelled your “definitely the final form” of your domain from day 0.
Oh and TDD?! Ah yes those perfectly defined unit cases you write for implementation details. The best comment I read recently (sorry I can’t find it) something akin to “The first unit I write is to validate the intended side effects through properly exercising associated mocks”
As with everything there is no “best way” to do something, but in software engineering… there are far more bad “best ways” than best “best ways”
DDD is a good way to extract the business logic from the implementation.
By modelling the business you raise the business logic up to a 1st class element.
By implementing the business objects you encapsulate their functionality in the business.
The words "Account" or "Outstanding Balance" have business meanings. Modelling them allows you to express the business logic explicitly.
It also allows you to create tests that are related to that business logic, not the implementation.
You can still "build what you need and deal with the consequences of inevitable change later".
Model what you need to build, the business is going to have to make changes to that model to implement their changes, IT systems are a detail.
Change by extending and changing the DDD models.
To reverse the question, how do you write code that "does what you need" without understanding the domain?
There's a huge difference between understanding the domain and modelling it as objects. Accounts and Balances have no behavior.