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

41–50 of 175 posts

Re: Why Domain Driven Design?

#41

Post by NicoJuicy »

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

Re: Why Domain Driven Design?

#42

Post by BulgarianIdiot »

est wrote: post #14
BulgarianIdiot wrote: post #5

I thought the DDD hype has died down a bit, but I guess not. Eric Evans (inventor of DDD) has said in recent years that unfortunately once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear. People do NOT have the discipline to do DDD correctly. But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "serv…

> once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear Conway's law: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

Precisely. But this is how it should be. The service is a part of the team, but automating the "mundane things" that people can delegate to machines, instead of doing them manually themselves.

This is why, BTW, I'm so dismayed Elon Must fired 85% of Twitter. Now many of their critical services have teams of zero or one developer. Those are basically dead services walking.

Re: Why Domain Driven Design?

#44

Post by pydry »

turtleyacht wrote: post #23
alfonsodev wrote: post #15

Earlier quoted context omitted.

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

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…

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

Re: Why Domain Driven Design?

#45

Post by hcarvalhoalves »

BulgarianIdiot wrote: post #37
goostavos wrote: post #27

Earlier quoted context omitted.

>But do you know what helps? Having physical boundaries you can't cross so easily. Rarely have I disagreed with something more strongly :) If a team lacks the discipline/skill/wherewithal to create good boundaries within a single code base when stakes are at their lowest, they absolutely don't have the skill or discipline to do ahead of time, across N code bases, and with a network in between all of them. Breaking yo…

You can disagree with it and blame the developers, but the fact is that DDD fails basically every time, unless physical boundaries stop you from failing. It's like saying a good driver won't have an accident on a sharp corner of an icy road, but yet you have a ton of accidents on that corner on an icy road. Facts are facts. Just as it's a fact you can't hope every organization to be staffed by 100% geniuses who never…

Microservices alone don’t solve the shared mutable state problem, and make it even worse w/ network and eventual consistency.

Re: Why Domain Driven Design?

#46

Post by _bax »

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…

The same is what I did every new product. And it works.

And I found not a excel aternative for this job.

Re: Why Domain Driven Design?

#47

Post by kxc42 »

Pandabob wrote: post #6

For all the Python devs reading this, a book that aims to cover DDD from a Python perspective is Architecture Patterns With Python [1]. It's free to read online and all the code can be found in Github. [0]: https://www.cosmicpython.com/

Funny coincidence: just one week ago I and a colleague of mine started with "pytest-arch" [1], a pytest plugin to test for architectural constraints. On purpose we kept it very simple. It is already usable and works well, at least for our use cases.

You can use it to check e.g. if your domain model is importing stuff that it should not import.

We are planning to publish it soon on pypi.

[1]: https://github.com/jwbargsten/pytest-arch

Re: Why Domain Driven Design?

#48

Post by Throw10987 »

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 have done similar prototyping in docs, whiteboards, CSV files... The flow is to focus on the data and what are the constraints(rules) on updating the data. The prototyping of api's, screens can come later off of a firm foundation of data, calculations and rules for creation and change.

Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)

Re: Why Domain Driven Design?

#49

Post by pfarrell »

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

Not the OP, but I’ve tried this before too. A huge benefit is that the everyone at the table understands excel and isn’t intimidated during the conversation. Understanding the domain as an engineer is the toughest, most important, and most rewarding part of DDD imho.

Re: Why Domain Driven Design?

#50

Post by tester756 »

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…

It sounds like you started designing system from database perspective

But doesn't this "skew" your domain model in code by affecting your thoughts by technical details?

I'd prefer start with some event storming session? visualization of system and connections

then design proper domain model, correct abstractions, events between those modules inside system

then just implement persistence layer with mapper from domain model to database model which in the case of SQL contains those technical details like cache fields, FKs, etc.

Post reply on HN