Ответ 1
Существует два основных способа думать о бизнес-правилах при разработке вашего домена.
1.) Объекты домена являются базовыми POCO/DTO. И вы передаете их в службы домена. Эти службы могут быть такими же простыми, как и другой класс, или они действительно могут быть фактическими службами, сидящими на другом сервере.
var user = repository.Find(x => x.UserName == userName);
if (userLogonService.IsValidUser(user, password)) {
userLogonService.UpdateUserAsLoggedOn(user);
}
repository.SaveChanges();
2.) Объекты домена содержат свою собственную логику работы. Это ближе к тому, за чем последуют многие шаблоны MVC. И поскольку вы спросили, это модель, которую я предпочитаю.
var user = repository.Find(x => x.UserName == userName);
if (user.CheckPassword(password)) {
user.LogOnNow();
}
repository.SaveChanges();
Оба являются полностью действующими шаблонами. # 1 имеет дискретный уровень бизнес-операций, но страдает от модели анемичного домена. # 2 может привести к большим доменам, если домен начинает усложняться, или если модель может многое сделать.
РЕДАКТИРОВАТЬ # 1: Ответ на John Kraft
Oven.Bake(myPizza) vs. myPizza.Bake()
Я в основном согласен. У вас есть одно обслуживание в духовке, или у вас есть десятки доступных печей, хранящихся в репозитории печи, где печь - это еще один объект домена? В № 2 печь является частью домена. Как я обычно делаю моделирование домена, большинство существительных являются сущностями домена, если вы на 100% не уверены, что есть что-то одно.
Но что-то случается с пиццей, когда она выпекается.
interface ICanBeBaked {
int BakeMinutes { get; }
int BakeTemp { get; }
void Bake();
}
class Pizza : ICanBeBaked {
int BakeMinutes { get { return 15; } }
int BakeTemp { get { return 425; } }
void Bake() {
// melt cheese!
this.isBaked = true;
}
}
class Oven {
void Bake(ICanBeBaked thingToBake) {
// set the temp, reserve this oven for the duration, etc.
thingToBake.Bake();
}
}