Как отделить классы домена от первого уровня кода EF и реализовать DDD в проекте

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

   public class TestDBContext : DbContext
    {
        public TestDBContext()
            : base("name=TestDBContext")
        {
        }

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            //modelBuilder.Configurations.Add(new vwCustomerConfiguration());
            Database.SetInitializer<TestDBContext>(null);
        }

        public DbSet<Customer> Customer { get; set; }
        public DbSet<Addresses> Addresses { get; set; }
        public DbSet<Contacts> Contacts { get; set; }
        public virtual DbSet<vwCustomer> vwCustomers { get; set; }
        public DbSet<vwMyCustomers> vwMyCustomers { get; set; }
    }

клиент, адрес, контакт и все доменные классы находятся в одном проекте, но я хочу поместить все эти доменные классы в другой проект.

просто посмотрите новую иерархию проектов, которую я думаю реализовать. все имя проекта будет начинаться с моей компании, а затем сделать и имя проекта

вот оно

1) Impex.Домен

2) Impex.Хранение

3) Impex.Бизнес

4) Impex.ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС

таким образом, у меня будет 4 слоя, и это домен, хранение, бизнес и пользовательский интерфейс. Storage, Business and UI эти 3 слоя будут иметь ссылку на доменный слой, потому что эти 3 слоя Storage, Business and UI могут использовать доменные классы.

UI будет передавать данные в бизнес-слой и полученные данные из бизнес-слоя. business layer снова будет говорить со слоем хранения, где код EF сначала будет реализован для взаимодействия с БД.

если я могу успешно завершить свой проект после 4 слоев, то люди должны считать, что мой проект основан на шаблоне DDD или нет ?

так скажи мне, правильно ли я думаю. пожалуйста скажите мне все ваши предложение и наведение. если кто-то может предвидеть какие-либо проблемы, то также, пожалуйста, знайте меня в деталях. спасибо

1 ответ

  1. Ваш вопрос, кажется, в основном вокруг структуры вашего решения, как и с большинством вещей в нашей отрасли, как только вы понимаете принципы вещи (DDD в этом случае), структура, кажется, сортирует его самостоятельно.

    Я бы указал на пару вещей, чтобы помочь вам на вашем пути

    1) Impex.Домен

    • Держите объекты чистыми не ссылайтесь на EF из этого проекта
    • Захват вашей бизнес-логики в ваших сущностях и агрегатах, а не в слое «бизнес», ваши сущности должны отвечать на события и действия, а не иметь «слоя», который говорит ему, что

    Как плохой пример, сделайте что — то вроде

    employee.takeLeave(days)
    

    Вместо

    employee.daysOff = days;
    

    т. е. изменение состояния Сущности должно быть записано внутри сущности.

    2) Impex.Хранение

    • Поскольку вы используете EF (и не собираетесь загрязнять свои доменные модели атрибутами , связанными с EF), вам придется использовать Fluent Api для настройки вашей модели EF (см. msdn, ef tuts и т. д., Чтобы получить некоторые идеи), в частности, первичные ключи и индексы должны быть настроены здесь.

    Что-то вроде

    modelBuilder.Entity<Employee>().HasKey(t => t.EmployeeID);
    
    • Кроме этого ничего не выходя здесь используйте стандартные паттеры репозитория и т.д.

    3) Impex.Business & Impex.ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС

    • Как упоминалось в пункте 1, нет смысла иметь businessслой, скорее это будет слой ApplicationилиService, здесь вы загрузите сущность или агрегат и вызовете работу, которая будет завершена.
    • Также ответственность слоя будет заключаться в сопоставлении между ViewModels & / или Request & Response POCOs( отправленными в и из вашего UI / Api), вы не будете предоставлять свои модели домена за пределами границы домена см. гексагональную архитектуру

    Последняя нота:

    DDD не диктует архитектуру! Это набор принципов, которыми вы можете руководствоваться, но вы можете реализовать как 1 Уровень, 3 уровня, CQR или любой другой архитектурный шаблон, который вам нравится, пока вы придерживаетесь арендаторов DDD.

    Удача.