Дотримуйтесь єдиного формату даних у шарі або компоненті.

Не змішуйте різні типи компонентів на одному логічному рівні.

Не перевантажуйте компонент функціональністю.

Реалізуйте слабке зв'язування шарів за допомогою абстракції.

Максимально ізолюйте наскрізну функціональність від бізнес-логіки програми.

простота переходу на DDD

простота розгортання

продуктивність

Керованість

можливість використовувати функціональні платформи

обмін інформацією

простота розробки

Ізоляція

3-рівнева архітектура

N-рівнева архітектура

DDD

Сервісно-орієнтована архітектура

Шина повідомлень

стиль проектування, в якому взаємодії між програмами здійснюються шляхом передачі (зазвичай асинхронної) повідомлень через загальну шину.

парадигма проектування, заснована на розподілі відповідальності програми або системи між окремими багаторазово використовуваними та самостійними об'єктами, що містять дані та поведінку.

у типових реалізаціях використовується маршрутизатор повідомлень, або шаблон Publish/Subscribe (Публікація/Підписка) та система обміну повідомленнями, така як Message Queuing (Черга повідомлень).

визначає додатки, що надають та споживають функціональність у вигляді сервісів за допомогою контрактів та повідомлень.

принцип використання програмної системи, яка може приймати та надсилати повідомлення по одному або більше каналах зв'язку, забезпечуючи таким чином додаткам можливість взаємодії без необхідності знання конкретних деталей один про одного.