Model View Controller is a well known pattern, which was described in the late 1970s. Since then, it is widespread architectural pattern, which influenced many frameworks and applications. For example in Java's well known framework [Spring](https://spring.io/guides/gs/serving-web-content) has element which is called **`@Controller`**, which represents a group of endpoints to handle input. Laravel is a PHP framework which is based on the MVC architecture.

MVC implies separation of concerns, where each element is responsible for a specific role.

**Model** - Model is responsible for managing data, business logic, business rules. Commonly used pattern, Domain Model, perfectly fits into MVC. Model is represented in the user interface(UI). UI in MVC is View.

**View** - View is responsible only for a rendering of a model. It can be a single template or by UI framework (library) rendered HTML. In MVC UI layer must not contain business logic, routing, orchestration, database querying. Only rendering the model representation. All these concerns are handled by a Controller element.

**Controller** - Controller accepts input, queries domain model object from a Model, calls services(notifications, logging, mutates data, queries other data sources). Prepares model for the UI, gets the View element. Combines View with the Model and returns HTML to the user.

Separation of an application code to different elements, has multiple benefits:

- each element can be tested in isolation, without a big effort. You can test your Model and View as a pure function. Model can be a complex component, with thousands of business rules and interrelated domain entities logic. Defining and testing those can become challenging. If you will add another layer of complexity, testing it in the presentation layer, you will lose the ability to test or to maintain tests.

- The concerns are fundamentally different. In enterprise applications, separate roles of employees are developing separate layers. For example business analysts will define the domain and business rules. UI developer will develop UI components/views to render a model. Backend developer will manage input to the controller.

- Having separate View from Model layers provides a possibility to implement different representations for different user groups. For example front office with customers, and back office with the employees working on a product, will have different representation of the Model and different application capabilities.

Since the 1970 pendulum swings from the server rendered application to the client rendered application (SPA, single page application), back and forth. MVC is not always applicable, though it even not always can be applied. This architectural pattern must be used to maintain application complexity. If the application is very small and there is no plans to grow this application, the MVC is a complexity itself, that needs to be managed. The majority of the internet is simple representational pages, created with Wordpress on PHP with a help of UI style utils/components like bootstrap and wordpress PHP plugins. On the other side enterprise application with a terabytes of data and millions of users with myriads of roles/privileges/use cases which you (as a developer/architect) need to handle.

MVC is about the separation of concerns, this means that you need to work hard to enforce it. Enforcing the separation can become challenging. On one hand you have requirements for complex interface, where developer wants to include the domain logic in the representation. On another hand you have a requirement to isolate business/domain logic from the representation. Which is possible, but it can become difficult, if incorrect abstraction is used. This separation can fail if:

- there is not architectural governance in the development process.

- developer will chose the environment, which is know for him. If he needs to switch tools/programming languages/repositories, most likely he will avoid it and mix the concerns.

- tools provided for developers are flexible enough to mix concerns. React with JSX, as an example, is the most powerful templating language for HTML (comparing to mustache, pug or others).

- time constraints are dictating the technical decision.

- current architecture does not support (or the complexity is too high to implement in other environment/tool/place) the required feature to be implemented in the Controller or Model.

Model View Controller MVC

In the book Patterns of _Enterprise Application Architecture by Martin Fowler_ two patterns are defined to handle business logic in the system. I do not think that much have changed since then. The IT industry evolved, but these patterns are still applicable to this day. I will unpack what those patterns mean and how they are applicable now.

**Domain model** is a pattern where object representing the model also contains the behavior and/or business rules in itself.

- ✔️ data together with the behavior

- ✔️ easy to extend

- ✔️ easy to comprehend / observe if applied correctly

- ❌ requires more effort and experience to implement

- ❌ may be overhead for a simple domain

**Transaction script** is a pattern where a separate script/object/function/service loads the data validates/modifies it and saves to the database.

- ✔️ requires less effort and experience to implement

- ✔️ fits simple domain applications

- ❌ anemic model, which is considered as an anti-pattern by a Martin Fowler

- ❌ hard to maintain / extend / observe on a more complex domain

Both of these patterns are pretty abstract and can be applied today with other architectural and design patterns. Each of those has pros and cons. You can use these pattern in your server side rendered UI MVC application with, react server components, PHP or Java server pages.

## **Difference**

The difference between those patterns is complexity. Complexity of implementation, extensions and support. Domain model can harder to implement initially. But it reduces the complexity, when the model is evolving, getting more complex. Keeping business logic in one place with the domain reduces the complexity of extension and refactoring. On the other hand transaction script separates data from the behavior. At the start it is easier to model you data and write a transaction script to handle business rules. But this approach will not scale, with the size of your model and the domain complexity.

## **Challenges**

At the time _Martin Fowler wrote the book Patterns of Enterprise Application Architecture_ was written, the standard UI architecture was HTML rendered on server with a small amount of interactivity sprinkled by javascript. All logic could be handled by both patterns on the server. Mostly it is MVC pattern for a web server with a input controller acting as a mediator. Today the expectations of the UI/UX have changed. UI is way more interactive - UI applications handles routing, validation, data initialization and manipulation, UI flow management, security and whats not. Previously UI was not responsible for all those things. This is why implementing business logic in the maintainable manner is crucial for a modern UI application. Domain model is one of the options, which must be considered. If you will leave the majority of these concerns on the server, then UI will request those. Multiple requests will degrade the responsiveness of an application.

## **Examples**

For example consider case when you need to validate the 1mb json data. You have thousands of business rules, which must be evaluated, to ensure the data is valid. During the data gathering process you will make thousands REST API calls to the server to validate the data, to provide instant feedback on entered values. If you will choose to make validation once per tab/dropdown/card/step, then user will have a bunch of errors after he completed the step. This can be a tradeoff of keeping the logic on the backend and requesting this logic from the server.

- using transaction script you will end up with thousands of functions, with duplicated logic between those and the code which is hard to comprehend.

- using the domain model pattern your business rules will be "managed" together with the model. Rules will be kept with the domain which matches the Single responsibility principle.

Domain Model vs Transaction Scripts

Domain driven design (DDD) is a methodology for designing software with a focus on the domain. DDD is one of the main practices used in the microservices development. I'll cover 3 main concepts of the DDD:

- Ubiquitous Language - use the same language/terms in the code and in the business. This allows programmers to talk to the business people without misinterpretation.

- Aggregate - Related objects, that form a consistency boundary and are treated as a single unit. For example in the "Customer" domain, "Address" is an aggregate.

> An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each aggregate has a root and a boundary. The boundary defines what is inside the aggregate. The root is a single, specific ENTITY contained in the aggregate.

_Domain Driven Design, Eric Evans_

- Bounded Context - a logical and physical boundary around a coherent and consistent domain or subdomain

What if you already have a domain and want to slice it to migrate from the monolith to the microservices, for example? You can do this using these patterns:

- Volatility - split by the performance sensitive parts

- Data - split by usage or restrictions on the data

- Technology - split by a technology stack

- Organizational - align with the company organizational structure

_Microservices, 2nd edition by Sam Newman_