Patterns of Enterprise Application Architecture-Day 1

Heloooooooooooooo 😄
For the next days , i give myself a challenge to write a little post about what i have read in that book and what impresses me 😄

So for Today, let's go.

Enterprise Application

I’ll start with examples. Enterprise applications include payroll, patient records, shipping tracking, cost analysis, credit scoring, insurance, supply chain, accounting, customer service, and foreign exchange trading. Enterprise applications don’t include automobile fuel injection, word processors, elevator controllers, chemical plant controllers, telephone switches, operating systems, compilers, and games.

• Persistent Data

Enterprise applications usually involve persistent data. The data is persistent because it needs to be around between multiple runs of the program—indeed, it usually needs to persist for several years. Also during this time there will be many changes in the programs that use it. It will often outlast the hardware that originally created much of it, and outlast operating systems and compilers. During that time there’ll be many changes to the structure of the data in order to store new pieces of information without disturbing the old pieces. Even if there’s a fundamental change and the company installs a completely new application to handle a job, the data has to be migrated to the new application.

• Lot Of Data

There’s usually a lot of data—a moderate system will have over 1 GB of data organized in tens of millions of records—so much that managing it is a major part of the system. Older systems used indexed file structures such as IBM’s VSAM and ISAM. Modern systems usually use databases, mostly relational databases. The design and feeding of these databases has turned into a subprofession of its own.

• Access data concurrently

There’s usually a lot of data—a moderate system will have over 1 GB of data organized in tens of millions of records—so much that managing it is a major part of the system. Older systems used indexed file structures such as IBM’s VSAM and ISAM. Modern systems usually use databases, mostly relational databases. The design and feeding of these databases has turned into a subprofession of its own. Usually many people access data concurrently. For many systems this may be less than a hundred people, but for Web-based systems that talk over the Internet this goes up by orders of magnitude. With so many people there are definite issues in ensuring that all of them can access the system properly. But even without that many people, there are still problems in making sure that two people don’t access the same data at the same time in a way that causes errors. Transaction manager tools handle some of this burden, but often it’s impossible to hide this from application developers.

• Lot Of user interface screens

With so much data, there’s usually a lot of user interface screens to handle it. It’s not unusual to have hundreds of distinct screens. Users of enterprise applications vary from occasional to regular, and normally they will have little technical expertise. Thus, the data has to be presented lots of different ways for different purposes. Systems often have a lot of batch processing, which is easy to forget when focusing on use cases that stress user interaction.

• Integrates with other systems

Enterprise applications rarely live on an island. Usually they need to integrate with other enterprise applications scattered around the enterprise. The various systems are built at different times with different technologies, and even the collaboration mechanisms will be different: COBOL data files, CORBA, messaging systems. Every so often the enterprise will try to integrate its different systems using a common communication technology. Of course, it hardly ever finishes the job, so there are several different unified integration schemes in place at once. This gets even worse as businesses seek to integrate with their business partners as well.

• Business Logic

Then there’s the matter of what comes under the term “business logic.” I find this a curious term because there are few things that are less logical than business logic. When you build an operating system you strive to keep the whole thing logical. But business rules are just given to you, and without major political effort there’s nothing you can do to change them. You have to deal with a haphazard array of strange conditions that often interact with each other in surprising ways. Of course, they got that way for a reason: Some salesman negotiated to have a certain yearly payment two days later than usual because that fit with his customer’s accounting cycle and thus won a couple of million dollars in business. A few thousand of these one-off special cases is what leads to the complex business “illogic” that makes business software so difficult. In this situation you have to organize the business logic as effectively as you can, because the only certain thing is that the logic will change overtime.

Patterns

The focus of the pattern is a particular solution, one that’s both common and effective in dealing with one or more recurring problems. Another way of looking at it is that a pattern is a chunk of advice and the art of creating patterns is to divide up many pieces of advice into relatively independent chunks so that you can refer to them and discuss them more or less separately.
A key part of patterns is that they’re rooted in practice. You find patterns by looking at what people do, observing things that work, and then looking for the “core of the solution.” It isn’t an easy process, but once you’ve found some good patterns they become a valuable thing. For me their value lies in being able to create a book that serves as a reference. You don’t need to read all of this book, or all of any patterns book, to find it useful. You just need to read enough to have a sense of what the patterns are, what problems they solve, and how they solve them.