Проблема с правильной архитектурой

[Mozart]

Всем привет. В связи с нехваткой опыта в архитектурных решениях прошу подсказать как правильно сделать.
Речь идет о сервисном слое, разрабатываемом для kohana 3.
Объявления о продаже технике. Несколько категорий техники. Одна таблица главная, в которой содержатся все главные параметры объявления и побочные с параметрами, по одной на каждую категорию техники. Т.к. категории и параметры будут очень редко меняться, это по-моему наилучший вариант для моего случая, чтобы сильно не усложнять систему и быстро проводить поиск и сортировку. Но это не то, о чем сам вопрос.

Чтобы никого не запутать, термин модель в данном изложении - объект для работы с базой данных, получение, вставка данных, никакой бизнес логики.
Сервис, сервисный слой - непосредственно сам сервисный слой, бизнес-логика.


Сам сервис:
Все параметры техники (поля) заранее есть в конфиге.
Есть родительский класс техники и наследники на каждую категорию, наследники содержат в себе идентификаторы полей, которые должны использоваться для данной категории.
Есть родительский класс валидации и два наследника - в них определены правила валидации для добавления, редактирования объявлений. Первый наследник - валидация от неавторизованного пользователя. Второй, соответственно от авторизованного. Также есть класс для работы с полями, группировка, подготовка для вывода, определение главных полей для вывода в списке техники и т.п.
Главный вопрос как это все связать в единую систему красиво.
Как создавать объекты, сначала создавать нужные и передавать их в сам класс сервиса, или передавать в сервис флаг идентификации пользователя, и уже в конструкторе фабрикой создавать нужные мне объекты(также и с категорией техники)?
Работа с базой данных внутри сервис - передавать в конструктор модель или также в сервисе создавать нужную модель и работать с ней?
Как правильно обеспечить связь класса техники и класса полей? ( Класс полей получает все поля из конфига, нужные поля из класса техники, создает массив с нужными полями и их параметрами и уже в нем есть все поля для данного типа техники, с которым сейчас и идет работа).
А может я и совсем не в ту степь ушел.
Хотелось бы сразу отметить, что для обучения хотелось бы все полученное покрыть тестами, поэтому и не хочется сразу облажаться с архитектурой. Проект для себя, поэтому никаких ограничений нет.
Теоретические знания основных патернов есть. Чего нету - прочитаю и разберусь. Можно смело выражаться знакомыми и незнакомыми словами.

 

[tz-lom]

не передавать в сервис модели,а из сервиса обращаться к моделям
на каждом уровне абстракции код должен включать в себя вызовы самого себя и вызовы объектов на один уровень абстракции ниже
передавать в конструктор сервиса модель - если модель абстрактна а не специфична, и разумеется если их больше одной которые могут передаться

 

[Mozart]

на каждом уровне абстракции код должен включать в себя вызовы самого себя и вызовы объектов на один уровень абстракции ниже

То есть в моем случае будет правильно передать в конструктор сервиса флаг авторизации и идентификатор категории техники?

 

[tz-lom]

Mozart
не могу сказать точно,не видел вашего кода,но похоже на правду
да,и я бы не таскал флаг авторизации,а имел бы объект "пользователь" который соответственно несёт на себе группу,имя,мэйл,и.т.д ну и имел бы группу "незареганные" ,соответственно для анонимуса делаем пустой объект с дефолтными полями ,а все валидации доступов уже работают по единой схеме "этой группе можно,а этой-нет"