Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Domain Driven Design?

yehohanan7.medium.com

Post reply on HN
Print view View original

171–175 of 175 posts

Re: Why Domain Driven Design?

#171

Post by kingdomcome50 »

stevebmark wrote: post #170
kingdomcome50 wrote: post #158

Earlier quoted context omitted.

The following is not an endorsement of DDD. There are many glaring issues with the ideas presented in that linked "take down" of DDD. I can forgive the early strawman comparing "spreadsheets" to bespoke software solutions. As if they cover exactly equal problem/solution spaces. Fine. I'll play along... I can even forgive failing to understand that DDD is a design methodology, not an architecture; That DDD in no way p…

This confirms my suspicion that "domain" has no definition. If "storing data" is a domain than anything can be a domain, and the word is meaningless. There are logical groupings of nouns and functionality into services / modules / orthogonal parts of the software. Aggregate root is one useful term here, domain is not. And for me it further reinforces the point of the article: design functional horizontal layers, not…

Come on now... You know perfectly well that "storing data" means something different to database software than some shitty LoB app. Let's not be so imprecise as to give off a disingenuous impression. The article makes almost no argument against DDD, and in fact could be a case study supporting the opposite conclusion! The author confuses architecture with design in every important way (similar to your "horizontal layers" comment).

DDD is not about how software is physically organized nor how it is deployed. You can have a traditional N-tier architecture AND follow DDD. The domain model is a logical model used to abstract the functional requirements of a system. It doesn't "lock" you in anymore than whatever else you have in place serving the same purpose. You cannot simply avoid your functional requirements. DDD is a methodology with the specific goal of drawing boundaries (answering "what" goes "where") in such a way to minimize the cost of change. If your resulting design is not doing so, you have simply failed to model your domain in a useful way.

In the author's case, maybe they really did need a generic "data integration" or "workflow engine" application. That's not an unreasonable assumption. And it follows that coupling those kinds of applications to the data/workflows contained therein would lead to all sorts of problems.

But surely he is not arguing that every application should be designed as a platform? It's considerably more difficult to design and maintain a "workflow engine" than "a single workflow", or a "data ingestion" application than to "just ingest the data". Most of the important bits in the above are already abstracted away from users.

Re: Why Domain Driven Design?

#172

Post by Yhippa »

NicoJuicy wrote: post #41
bob1029 wrote: post #34

My definition of DDD involves drawing up a series of relational tables in excel and reviewing those with the business stakeholders. If the product is like most, I'd then convert those excel workbooks to SQL schemas and start building some vertical slice demos. None of this has anything to do with micro services, source control, etc. The schema (domain) is the most important part of the product. If your manager can un…

Do you have an example of this flow somewhere? I never thought about prototyping it in excel and it sounds weird. I'm intrigued

I actually like to screen-share or project this: https://start.jhipster.tech/jdl-studio/. You can update this real-time and see your ERD real-time.

Re: Why Domain Driven Design?

#173

Post by turtleyacht »

marcosdumay wrote: post #75
turtleyacht wrote: post #7

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 Programmi…

> 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 de…

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

Re: Why Domain Driven Design?

#174

Post by cies »

camgunz wrote: post #73
cies wrote: post #33

Earlier quoted context omitted.

> I think that Django is basically DDD/CQRS/SOA Sure you can do DDD in Django. But I do not find that framework inherently CQRS of SOA (not SOA due to it's monolithic nature). Maybe a monolith on BEAM (Erlang, Elixir) could be marked as SOA due to the nature of BEAMs concurrency model. > engineers aren't bogged down with irrelevant stuff like request (de)serializing Last Django app i saw sure had a lot of this boiler…

> Sure you can do DDD in Django. But I do not find that framework inherently CQRS of SOA (not SOA due to it's monolithic nature). Django has "apps", which--while they do run in the same process--aren't intended to use code from each other. They're supposed to have their own models/views/templates/migrations/etc. They're effectively different services, as long as you don't think a service has to be available at a diff…

> I'm skeptical of anything whose central claim is "I can easily turn front end data requests into SQL and back again in very few lines of code".

Same for me. The Elm video is showing off a toy, an interesting toy, but a toy. The presenter also says it's for now only useful for fun projects.

Something with a more mature backend in the same direction would Hasura (a GraphQL and authorization layer over Postgres) with a generated-from-the GraphQL-spec client library. A generator for Elm exists (which give you strong type-safety over the API barrier).

It does lead to a situation where SQL barely used. The GraphQL used to query the db is very SQL-like though :)

Re: Why Domain Driven Design?

#175

Post by camgunz »

cies wrote: post #174
camgunz wrote: post #73

Earlier quoted context omitted.

> Sure you can do DDD in Django. But I do not find that framework inherently CQRS of SOA (not SOA due to it's monolithic nature). Django has "apps", which--while they do run in the same process--aren't intended to use code from each other. They're supposed to have their own models/views/templates/migrations/etc. They're effectively different services, as long as you don't think a service has to be available at a diff…

> I'm skeptical of anything whose central claim is "I can easily turn front end data requests into SQL and back again in very few lines of code". Same for me. The Elm video is showing off a toy, an interesting toy, but a toy. The presenter also says it's for now only useful for fun projects. Something with a more mature backend in the same direction would Hasura (a GraphQL and authorization layer over Postgres) with…

I absolutely love Hasura. I basically never want to write a backend API again after using it. But yeah it is a GraphQL to SQL compiler (and yeah all the attributes are like "where", "aggregate", it obviously is SQL-in-GraphQL), which... yeah let's just use SQL everyone, come on.
Post reply on HN