> DDD sounds amazing, but y'all the pull requests are usually a dozen files with tiny changes. At least from what I have seen.
When I've used it, a typical PR is about a Query or a Command, that calls a repository to retrieve an entity maybe performs some logic using that domain entity and stores it afterwards, three layers, application, domain and infrastructure. If you have more changes that those 3 layers (I'd say 2 files minimum, maximum about 6 ? ).
Maybe the feature / user story is not granular enough ?
That sounds reasonable. Maybe the story included some extra things.
Comparatively, it's a regular occurrence to add at least three files for a Cucumber BDD test:
1. The .feature file and one or more
scenarios.
2. Adding one or more step defs to one
(or more!) step def files.
3. Adding a new page object file or new
methods to an existing page object.
4. Possibly, add them to a component file
and *then* call that from the page
object.
From that perspective, seems the number of files changed is not bad.
I wish I had a representative example on my end. We would be able to see quickly. On the other hand, maybe there was cruft or other extras associated with just starting out with DDD with the existing conventions.
I remember there was another thing that was an issue: updating an aggregate object (?) required manually comparing each field. So the method was having to do that, spanning a page of code.
On balance, DDD affords opportunities to create maintainable code.
Do you have any experiences where the codebase was in a badly-structured form of DDD?
(Given agile development, there are good and bad ways to execute it, for example.)
>Comparatively, it's a regular occurrence to add at least three files for a Cucumber BDD test
This is partly why I so dislike Cucumber.
The gherkin language is insufficiently expressive for most purposes and the syntax for parameterization is just...bad. Thats how gherkin stories end up being a glorified label - it's not an intrinsic BDD problem.
It can be difficult to wrangle Gherkin. I've tried to use "Writing Great Specifications" as a kind of guide. Reducing specs to (mostly) one each of Given, When, and Then seems to reduce UI steps.
Having agnostic specs is nice if the team moves from web app to, say, React Native: should still be the same feature set.
The con is QA looking for step-by-step test instructions have to look elsewhere (at the "code"). And, I still haven't seen a real example of QA, PM, and dev working together to write Gherkin :)
Tooling can help for some warts. Gherkin is line-oriented, so a parser is easier to write. Using ex or ed, one can generate a clickable webpage of specs to kick off a test.
Interestingly, the book above recommends DDD as a way to organize test specs. One suggested exercise is to highlight words from a spec and label them as one domain or another, and determine the core domain versus secondary ones.
Of course, one chapter or a few cannot describe DDD, but interesting to see that decomposition.
When I've used it, a typical PR is about a Query or a Command, that calls a repository to retrieve an entity maybe performs some logic using that domain entity and stores it afterwards, three layers, application, domain and infrastructure. If you have more changes that those 3 layers (I'd say 2 files minimum, maximum about 6 ? ).
Maybe the feature / user story is not granular enough ?