Kinds of Enterprise Application
Strive for a balance between flexibility and development speed. Adding flexibility too early, especially if it’s the wrong kind can introduce complexity, making future evolution harder and delaying deployment, which in turn postpones the benefits.
Premature flexibility isn’t foresight, it’s over-engineering that slows you down.
Thinking About Performance
Beyond latency and response time, responsiveness measures how quickly a system acknowledges a request before completing it. Users often perceive low responsiveness as sluggish, even if actual response time is fast.
For example; a loading spinner appears instantly when you hit “Submit,” even if saving the data takes a few seconds.
Efficiency is performance divided by resources. A system that get 30 tps on two CPU is more efficient than a system that gets 40 tps on four identical CPUs.
Layering
Layering is a technique to break apart a complicated software system. Breaking down a system into layers has a number of important benefits.
- You can understand a single layer as coherent whole without knowing much about the other layers.
- You can substitute layers with alternative implementations of the same basic services.
- You can minimize dependencies between layers.
Layering also has downsides.
- Layers encapsulate some, but not all things. As a result you sometimes get cascading changes. The classic example is adding a field in UI, must be in database, and thus be added to every layer in between.
- Extra layers can harm performance. At every layer things typically need to be transformed from one representation to another.
- But the hardest part is deciding what layers to have what the responsibility of each layer should be.
A guiding force of many layering patterns is to keep as few dependencies as possible between the domain model and other parts of the system.
The Three Principal Layers
Presentation logic is about how to handle interaction between user and the software. This can be as simple as command-line or text-based menu system.
Data source logic is about communicating with other systems that carry out tasks on behalf of the application. The biggest piece of data source logic is a database that is primarily responsible for storing persistent data.
Domain logic, also referred to as business logic. It involves calculations based on inputs and stored data, validation of any data that comes in from the presentation, and figuring out exactly what data source logic to dispatch.
Distribution Strategies
The First Law of Distributed Object Design: Don’t distribute your objects!
If you absolutely must distribute, minimize distribution boundaries and utilize your nodes through clustering as much as possible.
Read more about Marinescu Layers
Concurrency
You only get concurrency problems if the data you’re sharing can be modified. So one way to avoid concurrency conflicts is to recognize immutable data.
Another option is to separate applications that are only reading data, and have them use copied data sources.
Optimistic lock is about conflict detection while a pessimistic lock is about conflict prevention. The essence of the choice between optimistic and pessimistic locks is the frequency and severity of conflicts.
Isolation is an important properties of ACID. It is the result of an individual transaction must not be visible to any other open transactions until that transaction commits successfully.
General advice is to never make a transaction span multiple requests. A transaction that spans multiple requests is generally known as a long transaction.