Инкапсуляция доменов

[pro100taA]

Хотелось бы иметь возможность изолировать домен и предоставить только некоторый интерфейс наружу.
Чтоб домены имели свою внутреннюю логику, которая касается только этого конкретного домена.

Домены приведены как пример, это может касаться и lib который могут также инкапсулировать логику работы чего либо с чем либо, что в свою очередь не очень удобно все описывать в одном файле.

[tshemsedinov]

Про один файл не понял, можно каждый и в нескольких файлах писать, в чем проблема?

[pro100taA]

Каждый из этих файлов будет доступен извне.
Хотелось было изолировать некоторые файлы, чтоб они были доступны только внутри домена.
Чтоб домен мог иметь свою изоляцию и предоставлял некий интерфейс для работы извне.

[tshemsedinov]

Я не уверен, что понял правильно, но делать внутреннюю логику в /domain и /lib можно (чтобы она не была видна наружу). Возможно, сейчас это не очень удобный синтаксис, потому, что он направлен не на защиту интерфейсов, а на защиту внутреннего состояния модулей. Пример можно посмотреть вот тут: https://github.com/metarhia/Example/blob/master/application/lib/example/cache.js
Тут this.values виден из модуля, но не виден снаружи, если написать lib.example.values, то до этого свойства добраться нельзя, а до функций через, например, lib.example.set - можно. Если сделать вот так:

({
  local: {
    method1() {
      console.log('Hidden method');
    },
  },

  doSomething() {
    this.local.method1();
  },
})

То из модуля такие методы видны, а снаружи не видны.
А вот если ключи в верхнем регистре, то видны: https://github.com/metarhia/Example/blob/master/application/lib/utils.js
Вообще, изолировать одну часть приложения от другой - мало смысла. Изоляцию нужно делать между контекстами пользователей и между внешними зависимостями и приложением - это да, зависимостям нельзя доверять. А контексты полностью не изолируются, потому, что через код можно из разных контекстов обращаться к общему состоянию, это бывает нужно. Но такие обращения должны быть явными и доступ к общему состоянию мы чуть позже будем защищать абстракциями параллельного программирования, чтобы если кто завел общий счетчик лайков (просто пример) и мы хотим его инкрементировать из разных контекстов, то можно написать await domain.posts.like(postId), а сам метод защищен декларативно:

({
  concurrency: 1, // ограничиваем одновременные вызовы метода like
  timeout: 100, // да еще и таймаут исполнения ставим

  async like({ postId }) {
    const done = await isAlreadyLiked();
    if (done) return;
    await doLike();
  }
});

Такое нужно только для асинхронных методов, конечно обысное поле в js можно инкрементировать domain.posts.likes[postId]++ не опасаясь, что кто-то в это время его меняет. Но вот если чтение и запись такого счетчика разделяются асинхронными вызывами, то защищать нужно.

[pro100taA]

Возможно я плохо вник в реализацию и плохо доношу свою идею.

Идея заключается в том, чтоб модуль example имел свою внутреннюю логику, а наружу был доступен только какой-то файл который предоставляет интерфейс для взаимодействия, например какой-то index.js.

Но внутри этого модуля файлы могли взаимодействовать друг с другом, чтоб этот модуль имел низкую связанность и высокую зацепленность.

[tshemsedinov]

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

[pro100taA]

Понял, спасибо за развернутый ответ.

[muturgan]

[ересь]
предлагаю такой вариант:

(new class {
  #secret = 42;

  #getSecret() {
    return this.#secret;
  }

  publicMethod() {
    return this.#getSecret();
  }
});

А ещё можно в одном месте (скажем в lib/helper.js) написать

(class Helper{});

а в другом месте

...
const helper = new lib.helper();

[tshemsedinov]

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