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

marcosdumay

> 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.

turtleyacht

I guess a couple ideas:

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.

[2] https://github.com/google/rune