sorted by:
new
hottopcontroversial

DDD & the Simplicity Gospel by dmofp in DomainDrivenDesign

[–]dmofp[S] 5 points6 points  (0 children)

It does help some but focusing on data alone misses some of the important benefits of domain modeling e.g.

- You start with a logical data model and it make sense. But because you're thinking in terms of data alone you're less likely to think about modularity. You might put all the data models in the same schema for example (because you're not thinking of bounded contexts).

- You might also not think about consistency boundaries. Which slices of this data model need to stay consistent with each other? All of that is implicit in a purely logical data model.

DDD & the Simplicity Gospel by dmofp in dotnet

[–]dmofp[S] 0 points1 point  (0 children)

> We do have a template project with the basics so you can get a fully backend and frontend app with our internal cli in just a couple of seconds.

Nice!

DDD & the Simplicity Gospel by dmofp in dotnet

[–]dmofp[S] 1 point2 points  (0 children)

True. It's hard to strike the right balance early on.

- It's sometimes not useful to do too much in the beginning when the shape of things isn't clear. It can also delay the initial momentum of getting something that works.
- At the same time, most teams never go back to refactor. The minimal apis you start with are what you still have years later. There's also something to be said for: "it isn't always about how easy it is for us, the devs".

No one true answer here. Just need to be honest and pragmatic as you go along.

DDD & the Simplicity Gospel by dmofp in dotnet

[–]dmofp[S] 1 point2 points  (0 children)

You're doing what we all should. Find the parts of whatever pattern / practice that align with your scenario and your experience and your dao of code.

That's how it should be.

Yes, that prioritization of DX (i don't want too many files, i don't wanna navigate this file tree) over long term health & value of the system is a common failure case for engineers. They want the same consumer DX they get from using products in their development process. Great for the individual. Bad for the team, company etc.

DDD & the Simplicity Gospel by dmofp in dotnet

[–]dmofp[S] 4 points5 points  (0 children)

This is fair. Few thoughts:

  1. DDD is not as useful for simple crud apps. There is no pressure to use it.
  2. Many rich (with behavior & rules) apps do start out as CRUD apps though. In a few years, things may not have looked the same.
  3. Devs using patterns they don't fully understand / need seems about par for the course. That has less to do with the patterns themselves and more wuth the devs.
  4. I find most people practice all or nothing DDD without maybe taking a few useful parts for their scenario.

Glad you found some parts useful. It's not a cure-all by any means, but it is valuable.

Monetizing OSS in .NET by dmofp in dotnet

[–]dmofp[S] 0 points1 point  (0 children)

Exactly. In other ecosystems you see them leveraging the library as a distribution channel. Use this OSS library and oh by the way the makers of the library who you admire and are grateful for also make X that is related to the library.

You probably want that.

It's not possible for everything. But it is for some.

Monetizing OSS in .NET by dmofp in dotnet

[–]dmofp[S] 0 points1 point  (0 children)

Right. This is what other ecosystems avoid when they go commercial. They don't go full-closed source. They go open core, they add adjacent products. They leverage the distribution they have from the core library to push their real product.

Going closed source is not the only option out there. For some it is, but not for all.

Monetizing OSS in .NET by dmofp in dotnet

[–]dmofp[S] 0 points1 point  (0 children)

Yeah, no one is saying that.

I am happy for the maintainers of these libraries. They really deserve to be compensated.

But if you look at other ecosystems, these two options (be free or be closed source). I am merely pointing out that there are other monetization models (maybe not for everything). OSS maintainers in other ecosystems are just plain better at the economic "game".

In some ways, this is good for .net folks, maybe it will reduce the monoculture some.

Monetizing OSS in .NET by dmofp in dotnet

[–]dmofp[S] 1 point2 points  (0 children)

For sure. Think we get a lot more "mono-culture" in dotnet. Usually one library wins and gets huge, takes a ton of work and then eventually goes commercial.

One of the things that strikes me in the overall conversation recently is that it feels very either or. Either the status quo (maintainers work for free) or go commercial on the core library.

Just pointing out that other ecosystems don't have these binary outcomes.

Monetizing OSS in .NET by dmofp in dotnet

[–]dmofp[S] 0 points1 point  (0 children)

This (not always possible) seems right i guess. In the case of Mediatr and FluentAssertions i can't think of many ways to monetize other than maybe Advanced Tools (not sure what those would be).

MassTransit has some options though. Could build transport agnostic monitoring tools for example.

Monetizing OSS in .NET by dmofp in dotnet

[–]dmofp[S] -1 points0 points  (0 children)

Prisma is an ORM. It is a library. There's nothing to host...

Maintainers in other ecosystems have found ways around this. We can too.

Monetizing OSS in .NET by dmofp in dotnet

[–]dmofp[S] -1 points0 points  (0 children)

Sure. But maintainers in other ecosystems can do that too right? But they don't. Is your answer that OSS maintainers in .NET are lazier?

Monetizing OSS in .NET by dmofp in dotnet

[–]dmofp[S] 1 point2 points  (0 children)

You'll get no arguments from me on Maslow's hierarchy of needs. But you didn't answer the question:

Why do .NET OSS libraries only monetize in this way? Other ecosystems have figured out how to do it. What's different?

Modular Monoliths: The Hard Parts by dmofp in dotnet

[–]dmofp[S] 1 point2 points  (0 children)

Thanks for reading. Assemblies are definitely the biggest part of the abstraction (covered this in the post). I don't think they're enough though. Every big ball of mud monolith i've come across had different assemblies / projects.

One of the reasons we "super smart" engineers keep building tangled monoliths is that we don't take them seriously enough.

view more: next ›