domain-model

Well I've been trying to find out the difference between data mapper and repository, but up to now I still have not. It seems to me that the expert programmer said "Repository is another layer of abstraction over the mapping layer where query construction code is concentrated". It seems understandable but is still somewhat very abstract. I read this article on stackoverflow before, and it just made me even more confused: How is the Data Mapper pattern different from the Repository Pattern? I guess what I need are simple explanations and concrete/practical examples on how the two patterns

Been watching some Greg Young videos lately and I'm trying to understand why there is a negative attitude towards Setters on Domain objects. I thought Domain objects were supposed to be "heavy" with logic in DDD. Are there any good examples online of the bad example and then they way to correct it? Any examples or explanations are good. Does this only apply to Events stored in a CQRS manner or does this apply to all of DDD? I'm contributing this answer to complement Roger Alsing answer about invariants with other reasons. Semantic information Roger clearly explained that property setters don't

I had a discussion at work regarding "Inheritance in domain model is complicating developers life". I'm an OO programmer so I started to look for arguments that having inheritance in domain model will ease the developer life actually instead of having switches all over the place. What I would like to see is this : class Animal { } class Cat : Animal { } class Dog : Animal { } What the other colleague is saying is : public enum AnimalType { Unknown, Cat, Dog } public class Animal { public AnimalType Type { get; set; } } How do I convince him (links are WELCOME ) that a class hierarchy would be

I have been reading about domain driven design and how to implement it while using code first approach for generating a database. From what I've read and researched there are two opinions around this subject: Have 1 class that serves both as a domain model and a persistence model Have 2 different classes, one implementing the domain logic and one used for a code-first approach Now I know opinion 1) is said to simplify small solutions that do not have many differences between the domain and persistence models but I think it breaks the single responsibility principle and by that introduces a lot

To take advantage of the wide range of query methods included in java.util.stream of Jdk 8 I am attempted to design domain models where getters of relationship with * multiplicity (with zero or more instances ) return a Stream<T> , instead of an Iterable<T> or Iterator<T> . My doubt is if there is any additional overhead incurred by the Stream<T> in comparison to the Iterator<T> ? So, is there any disadvantage of compromising my domain model with a Stream<T> ? Or instead, should I always return an Iterator<T> or Iterable<T> , and leave to the end-user the decision of choosing whether to use a

I am deciding if I should use a Rich Domain Model over an Anemic Domain Model, and looking for good examples of the two. I have been building web applications using an Anemic Domain Model, backed by a Service --> Repository --> Storage layer system, using FluentValidation for BL validation, and putting all of my BL in the Service layer. I have read Eric Evan's DDD book, and he (along with Fowler and others) seem to think Anemic Domain Models are an anti-pattern. So I was just really wanting to get some insight into this problem. Also I am really looking for some good (basic) examples of a Rich

I am studying a Spring book and they mention Java domain model. What is that? A domain model (the term is not at all Java specific) is a class that models something in the problem domain, as opposed to a class that exists for technical implementation reasons. Domain model instances often need to be persisted in a database, and in Java, they typically conform to the Java Beans specification, i.e. they have get and set methods to represent individual properties and a parameterless constructor. Spring and other frameworks allow you to access these properties directly in your JSPs. For example, in