Timeline for Rich Domain Models -- how, exactly, does behavior fit in?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 27, 2013 at 17:00 | comment | added | Stefan Billiet | True, but that's not a reason to accept that reality. To continue in such a pursuit is to waste the time (and possibly reputation) of the developers and money of the customer. The proces I described is a relationship that needs to be built over time; it takes a lot of effort, but it yields much better results. There's a reason that "Ubiquitous Language" is often considered to be the most important aspect of DDD. | |
| Nov 27, 2013 at 16:18 | comment | added | maple_shaft♦ | @StefanBilliet In a perfect world I agree with you where a business expert has the time to sit down with developers. The reality of the software industry is that the business expert has no time or interest in being involved at this level or worse yet the developers are expected to just figure it out with only vague guidance. | |
| Nov 27, 2013 at 15:17 | comment | added | Stefan Billiet | To be frank, I think the only good design choice is a model that a business expert can reason about. You're building a model of a domain, for a business to use to solve certain problems within that domain. Splitting behaviour from domain entities off into services makes it harder for everyone involved, because you constantly have to map what a domain experts says to service code that bears hardly any resemblance to the current conversation. In my experience, you lose a lot more time with that, than typing boilerplate. That's not to say there are no ways around boilerplace code ofcourse. | |
| Nov 27, 2013 at 14:41 | comment | added | maple_shaft♦ | @StefanBilliet Those are good points about the fallacy of a universal domain model, but it is possible in simpler components and component interaction as I have done this before. My opinion is that translation logic between domain models can make for a lot of tedious and boilerplate code and if it can be avoided safely then that can be a good design choice. | |
| Nov 27, 2013 at 13:04 | comment | added | Stefan Billiet | 1)How can you separate business logic from the domain model? It is the domain in which this business logic lives; the entities in that domain are executing the behaviour associated with that business logic. The real world has no services, nor do they exist in the heads of domain experts. 2)Any component that wishes to integrate with you needs to build its own domain model, because its needs will differ and it will have a different view on your domain model. It is a longstanding phallacy that you can create one domain model that can be shared around. | |
| Oct 7, 2013 at 0:27 | history | answered | maple_shaft♦ | CC BY-SA 3.0 |