DDD sounds amazing, but y'all the pull requests are usually a dozen files with tiny changes. At least from what I have seen.
And the promise is "change is easy" or "impact to existing code is low." This may be true. Is it?
I have the Evans book. It may completely change the way I write code. But I also have "C Interfaces and Implementations," and that promises another. Yet another is Stepanov's "Elements of Programming," which by first chapter's end Feynman is telling me to read it again [1].
We just want to make Good Decisions about the code, right? Strategically (architectures) and tactically (pure functions).
I wonder if domain stuff surfaces naturally in SQL. Tables as types and subtypes. "Now build an app around me" feels like a different take from the usual "Now we just need the persistence layer."
[1] No Ordinary Genius: The Illustrated Richard Feynman
> I wonder if domain stuff surfaces naturally in SQL.
Only if your domain is very simple. Database types are not very expressive.
I wonder what is the minimum one must add to support actual people processes. Sum types and interfaces are a must, some kind of recursive namespace is clearly lacking, but those still don't seem sufficient.
Anyway, SOA is something that leads to a kind of segmented DDD. But the software development culture made such a mess with it that you simply can't do anything useful anymore once you acknowledge you are doing SOA.
Function farms. You implement functions as needed, making sure everything halts. The challenge is some users will certainly ask for loops or persist state, and you've handrolled an embedded no-code product.
Even in VBScript, one could chain functions (named as strings):
Dim Workflow : Set Workflow ' instantiate
.Step("SetupStuff")
.Step("DoThisThing")
.Step("DoOtherThing")
.Step("Customer1CustomFunc")
.Step("Customer2VerySimilarFunc")
Internally, the class enumerates in a loop for each record, so you save a level of indentation.
Sum types. I think this could be done with a table representing multiple types [1].
For example, an Organization table requires a Name field and represents subtypes Legal Org or Informal Org.
Legal Org subtype lives in the same table and uses Federal Tax ID Num, Corporation, and Govt Agency fields.
Informal Org uses Team, Family, and Other Informal Org fields.
> The subtypes within an entity should
represent a complete set of
classifications (meaning that the sum of
the subtypes covers the supertype in its
entirety) and at the same time be
mutually exclusive of each other (an
exception ... covered in the next
section).
Interfaces. Stored procs as functions could enforce preconditions. That could be aided by unit tests. Or a test generator, because checking for fields and field types should be straightforward, since the table defines them up front (static).
Recursion. Recently, Google says Rune lang supports something "easy" to do in SQL [2]:
> [Hierachical structures like family
trees] can be tricky to model in some
languages, yet is trivial in both SQL
and Rune
Pretty vague, but I know stuff like org charts can be done with CTEs and recursion (plus sweat and StackOverflow).
Is that what you mean by "recursive namespaces?"
> SOA is something that leads to a kind
of segmented DDD
> made such a mess with it
Yes, we needed to reinforce it at the infra/deployment level to get any meaningful separation. But as soon as a deadline looms, environments start to blur...
[1] Silverston, Len. The Data Model Resource Book (Revised Edition). Volume 1. Wiley. 2001.
> 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.
Oh--just that I couldn't understand the first chapter in Stepanov fully on first reading, so I need to read it again (and again, and again).
The Feynman reference is
Well, I asked him, “How can I read it?
It’s so hard.” He said, “You start at the
beginning and you read as far as you can
get, until you are lost. Then you start at
the beginning again, and you keep working
through until you can understand the whole
book.”
—Joan Feynman, Richard Feynman’s sister,
recalling a discussion with her brother
And the promise is "change is easy" or "impact to existing code is low." This may be true. Is it?
I have the Evans book. It may completely change the way I write code. But I also have "C Interfaces and Implementations," and that promises another. Yet another is Stepanov's "Elements of Programming," which by first chapter's end Feynman is telling me to read it again [1].
We just want to make Good Decisions about the code, right? Strategically (architectures) and tactically (pure functions).
I wonder if domain stuff surfaces naturally in SQL. Tables as types and subtypes. "Now build an app around me" feels like a different take from the usual "Now we just need the persistence layer."
[1] No Ordinary Genius: The Illustrated Richard Feynman