Действительно ли это - хорошая идея “переместить код бизнес-логики в нашу модель предметной области”?
Я читаю, в спящем режиме в Действии, и автор предлагает переместить бизнес-логику в наши модели предметной области (p. 306). Например, в примере, представленном книгой, у нас есть три названные объекта Item, Bid, и User и автор предлагает добавить a placeBid(User bidder, BigDecimal amount) метод к Item класс.
Полагание, что обычно у нас есть отличный слой для бизнес-логики (например. Manager или Service классы в Spring), что среди прочего контрольные сделки, и т.д. это - действительно хороший совет? Разве это не лучше для не добавления методов бизнес-логики к нашим объектам?
Заранее спасибо.
2 ответа
Как сказано
У нас есть отдельный уровень для бизнес-логики (обычно называемый уровнем обслуживания)
Domain-Driven-Design (DDD) заявляет, что вы должны поместить бизнес-логику в свою модель предметной области. И, поверьте, это действительно хорошо. Как сказано в книге действий POJO о сервисном уровне
- Он управляется прецедентами
- Он может определять границы транзакций
До
@Service
public class BidServiceImpl implements BidService {
@Autowired
private ItemRepository itemRepository;
public void placeBid(Integer itemId, User bidder, BigDecimal amount) {
Item item = itemRepository.getById(itemId);
if(amount.compareTo(new BigDecimal("0.00")) <= 0)
throw new IllegalStateException("Amount must be greater than zero");
if(!bidder.isEnabled())
throw new IllegalStateException("Disabled bidder");
item.getBidList().add(new Bid(bidder, amount));
}
}
После
@Service
public class BidServiceImpl implements BidService {
@Autowired
private ItemRepository itemRepository;
public void placeBid(Integer itemId, User bidder, BigDecimal amount) {
// itemRepository will retrieve a managed Item instance
Item item = itemRepository.getById(itemId);
item.placeBid(bidder, amount);
}
}
Логика вашего домена отображается следующим образом
@Entity
public class Item implements Serializable {
private List<Bid> bidList = new ArrayList<Bid>();
@OneToMany(cascade=CascadeType.ALL)
public List<Bid> getBidList() {
return this.bidList;
}
public void placeBid(User bidder, BigDecimal amount) {
if(amount.compareTo(new BigDecimal("0.00")) <= 0)
throw new IllegalStateException("Amount must be greater than zero");
if(!bidder.isEnabled())
throw new IllegalStateException("Disabled bidder");
/**
* By using Automatic Dirty Checking
*
* Hibernate will save our Bid
*/
item.getBidList().add(new Bid(bidder, amount));
}
}
При использовании домена -Driven-Design, ваша бизнес-логика находится в нужном месте. Но, иногда , было бы неплохо определить бизнес-логику внутри уровня службы. См. здесь почему
Одна из наиболее цитируемых статей по этому поводу:
«Модель анемической области» Мартина Фаулера. Стоит прочитать: http://martinfowler.com/bliki/AnemicDomainModel.html
Общая суть в том, что если ваша модель предметной области представляет собой чисто данные без поведения, вы теряете многие преимущества объектно-ориентированного проектирования.
или процитируем:
«В целом, чем больше поведения вы обнаружите в службах, тем больше вероятность того, что вы лишите себя преимуществ модели предметной области. Если вся ваша логика находится в службах, вы» он ограбил себя слепым ".