Tiêu điểm: Đâu Là Phần Quan Trọng Nhất Của Ứng Dụng
Wednesday, February 13, 2008 5:04:20 PM
Công nghệ ngày nay phát triển nhanh hơn trước rất nhiều. Trong môi trường ngày nay, một yêu cầu đặt ra là chúng ta làm như thế nào để có thể cung cấp cho các khách hàng những sản phẩm tốt đáp ứng cho việc đầu tư phần mền của họ. Nhìn lại, J2EE là được phổ biến hơn cả. Những phần mềm liên quan tới quản lý đã và đang được điều hành dựa trên J2EE và là nguyên nhân làm tăng đáng kể vốn đầu tư. Mọi thứ cũng xảy ra với COM+, ASP 3.0, etc. Những nhà quản lý được dự đoán sẽ tiết kiệm đáng kể khi sử dụng chúng. Hiện tại, một số nơi đã thực hiện được điều này. Trong khi đó có một số ứng dụng đã được viết trước đó, hiện tại đang được viết lại với những công nghệ mới hơn.
Tại sao như vậy? Bởi vì các ứng dụng không có phần lõi. Bởi phần lõi, theo tôi, là trung tâm của ứng dụng mà nó diễn tả business domain. Đặc trưng, đó là các Classes và interfaces. Việc tạo ra các Classes sử dụng COM+ hay J2EE không tạo ra một phần lõi của ứng dụng. Cốt lõi của ứng dụng không quan tâm tới công nghệ phụ cận. Phần lõi là domain model của bạn. Bởi vậy việc thiết kế chúng chính là phần quan trọng nhất của ứng dụng, tất nhiên, nó có thể thay đổi một cách linh động.
Look around and see if you can relate to this: A software team focuses much energy on making the database as good as possible and they create stored procedures to pull back the data as quickly as possible. They also consider the use cases of the screens that are necessary. Using technology X for the presentation, they make database table designs and stored procedures that return exactly what the screen needs to show to the user. Perhaps J2EE or COM+ is used in the passage of information from the database to the UI. Perhaps Enterprise Java Beans for COM+ components perform some transformation or calculations necessary for the screens.
Take a step back and remove the screens. Remove the database. Is there any application left? Can you point to any business rules or domain concepts left in the application after the presentation and storage components are removed? In my experience, I've had to answer "no" more than once. This is absolutely the wrong way to develop software.
Software systems should be resistant to climate change. The technology climate is always changing. The core is the most important part of the application, and it should be insulated against changes on the outside. Over time presentation technologies have changed many, many times. Data access technologies haven't sat still either. We still have the relational database, but the manner of using it is constantly changing.
Software health check: Take away the code used to talk to the database. Take away every screen. You should still have an application. You should be left with your application core or domain model and domain services. Everything should be intact.
Handle changes in technology gracefully. If your application has a healthy core, you will be able to upgrade to the next-generation UI. You'll be able to change your data access to use LINQ or an ORM without much impact. If you don't have a healthy core, any change in technology requires almost a wholesale rewrite.
Any software system is a large investment for a company. That software is expected to last a LONG time. By focusing on the core of the application (domain model), the software will be able to weather changes in the technology climate. By creating a healthy core, your software will be able to drop and adopt technologies as necessary. Let's stop rewriting and rewriting and start creating healthy software.






