tag:blogger.com,1999:blog-2526628884837213668.post93749945752151114..comments2024-03-27T00:14:35.505-07:00Comments on Adapting and Learning: Architectural Layers and Modeling Domain LogicLorenzo Deehttp://www.blogger.com/profile/00551506284562303520noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-2526628884837213668.post-28874307886763550262022-04-08T03:59:57.750-07:002022-04-08T03:59:57.750-07:00Great pushback on over-applying domain models.
Gr...Great pushback on over-applying domain models.<br /><br />Great writing too, super-clear and to the point, it could go straight onto Martin Fowler's blog. What about cross-posting on dev.to for wider visibility? It would make a good companion to this very good set of DDD articles: https://dev.to/peholmst/strategic-domain-driven-design-3e87Georgehttps://www.blogger.com/profile/07055879155666418867noreply@blogger.comtag:blogger.com,1999:blog-2526628884837213668.post-56303195498230574362017-01-05T18:10:43.170-08:002017-01-05T18:10:43.170-08:00Also on p. 86 (Chapter 6: Maintaining the Integrit...Also on p. 86 (Chapter 6: Maintaining the Integrity of Domain Models with Bounded Contexts)<br /><br />"Not all bounded contexts need to share the same architectural pattern. If a bounded context contains a supporting or generic domain with a low logic complexity, you might want to favor a more create, read, update, and delete (CRUD) style of development. If, however, the domain logic is sufficiently complex, it’s best to create a rich object-oriented model of the domain. Once bounded contexts are separated you can go a step further and apply different architectural patterns."<br />Lorenzo Deehttps://www.blogger.com/profile/00551506284562303520noreply@blogger.comtag:blogger.com,1999:blog-2526628884837213668.post-39213091620445350172017-01-05T18:09:19.316-08:002017-01-05T18:09:19.316-08:00Upon reading Patterns, Principles, and Practices o...Upon reading Patterns, Principles, and Practices of Domain-Driven Design (Scott Millett and Nick Tune), I agree with what they wrote on p. 64 (Chapter 5: Domain Model Implementation Patterns):<br /><br />"The majority of sub systems are CRUD based, with only the core domain requiring the domain model implementation pattern to ensure clarity or to manage complex logic. What you should not do is try to apply the domain model pattern for everything. Some parts of your application will simply be forms over data and will require just basic validation instead of rich business logic. Trying to model everything and apply object‐oriented practices would be a waste of effort that would be better spent on your core domain. Software development is all about making things simpler, so if you have complex logic, apply the domain model pattern; otherwise, look for a pattern that fits the problem you have, like the anemic domain model or the table module pattern."<br />Lorenzo Deehttps://www.blogger.com/profile/00551506284562303520noreply@blogger.com