[jeremycarter]

It's tricky to provide a really good example right now. I notice in the .NET world there are like these DDD "starter packs", and my god, they're just layers of maintainability hell. If you look at older OOP/DDD books you'll notice that the domain object has real world methods on it, just like as if it were from a UML diagram.

What you should end up with are plain OOPy objects that mirror the real world. They're not skewed or constrained by their database model. They shouldn't have any dependencies on your infrastructure layer. The object should encapsulate state, behaviour, validity and consistency.

An example (which is probably overkill) would be https://learn.microsoft.com/en-us/dotnet/architecture/micros...

The next post is about modelling an actor and it might provide more insight for you.

[ibgeek]

It's not clear from the article whether actors offer significant benefits (or disadvantages) for data modeling versus the traditional OO paradigm. The article reads more like an introduction that describes the problem and teases a solution rather a complete article that offers a solution and evaluation of it.

[jeremycarter]

That's fair feedback. I wanted to post it in 3 parts, but I see now I probably should have just made one large post.

[macintux]

You could always post the 3 parts simultaneously, so anyone who wants to dig deeper can continue into the series.