4 ms·

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

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

ssivark 4y ago
> Yet another is Stepanov's "Elements of Programming," which by first chapter's end Feynman is telling me to read it again [1]. I'm very curious what you mean by this -- is Feynman recommending Stepanov's book?
- turtleyacht 4y ago
  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 From https://rs.io/feynman-reading-difficult-things/ https://rs.io/feynman-reading-difficult-things/
  - layer8 4y ago
    That takes quadratic time though, assuming one “gets lost” with roughly constant likelihood throughout new text. I’m sure there must be a better way.
    - turtleyacht 4y ago
      It would indeed take forever, even assuming we are not only reading, but writing notes too. The only way through is to make it computable: writing programs and making it concrete. Another is to obsess over it externally: taping index cards up on the walls, ruminating on it in the bath, and transferring that to software. There's just too much to learn now. My bet is on first principles from cheap books, but the world keeps turning. What has worked for you?
alfonsodev 4y ago
> 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 ?
- turtleyacht 4y ago
  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.)
  - pydry 4y ago
    >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.
    - turtleyacht 4y ago
marcosdumay 4y ago
> 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 4y ago
  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 https://github.com/google/rune

ssivark 4y ago

> Yet another is Stepanov's "Elements of Programming," which by first chapter's end Feynman is telling me to read it again [1]. I'm very curious what you mean by this -- is Feynman recommending Stepanov's book?

turtleyacht 4y ago
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 From https://rs.io/feynman-reading-difficult-things/ https://rs.io/feynman-reading-difficult-things/
- layer8 4y ago
  That takes quadratic time though, assuming one “gets lost” with roughly constant likelihood throughout new text. I’m sure there must be a better way.
  - turtleyacht 4y ago
    It would indeed take forever, even assuming we are not only reading, but writing notes too. The only way through is to make it computable: writing programs and making it concrete. Another is to obsess over it externally: taping index cards up on the walls, ruminating on it in the bath, and transferring that to software. There's just too much to learn now. My bet is on first principles from cheap books, but the world keeps turning. What has worked for you?

alfonsodev 4y ago

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

turtleyacht 4y ago
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.)
- pydry 4y ago
  >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.
  - turtleyacht 4y ago

marcosdumay 4y ago

> 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 4y ago
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 https://github.com/google/rune