在网上也看了很多东西，关于JAVA软件架构方面的东西，现在还真是很难找到，不过，软件开发的架构基本是相同的。所以，我在网上查找了很多其他语言关于软件架构方面的文章。再这里也来说说自己对软件架构，特别是在JAVA项目架构方面的看法。说得不一定对，但这也是我几年来的总结吧。
1. 尽量不要考虑项目外的重用
许多人认为能提高软件的重用度是最好的，然而每个项目实际情况都会有所不同，在设计项目中的某个模块、方法时，过多的考虑项目外的重用，必然会增加项目的复杂度，增加对开发时间的开销。也许有人会说，这会减少下一项目的开销，试问，下一项目是什么项目？有什么需求？各方面有什么影响因素？有谁会在当前知道这一切。 如果真要重用，应该是在项目结束后再将可重用的部分提取出来，经过修改、优化后做为企业的可重用资产，而不是当前项目中的一厢情愿。考虑项目外的重用性，这是很多刚从事软件工作的程序员常犯的错误，往往是考虑得越多，反而做出来的软件达不到设计的效果，完不成基本的功能或者代码逻辑过多，程序功能不完善等等。
2.经常检查项目架构
项目架构通常是在项目实现开始前就已确定的东西，是一个总体的设计。然而，在这时，对项目需求的理解、复杂度的估计都还停留在一个初始阶段。如果在项目开发过程中不能随着对项目的理解而改进架构，必然让项目中的成员都按错误的架构去开发项目。所以，必须经常检查项目的架构，进行必要的重构。
3.重构
有人说，都写了这么多了，再修改不是浪费时间嘛。他可能没有想过，一个下午的重构可以加快以后几个月的开发速度，这节省下来的时间是无法想象的。再者，通过重构，通常能想到更多简单的方法来代替现有的实现，这样的经验，同样可以简化其他模块的开发。
4.避免过度集成，让每个模块只做自己的事
一个常见的OA开发例子是，在业务系统中通常会有许多的审批，很多人一下子肯定会想到把审批做成一个通用的模块。这是没有问题的，然而通常的问题是，太多的人将审批结束后的业务处理也放到了审批模块的业务逻辑中，其实，那些是各业务模块自己的事，审批应该只完成审批即可，至于审批结束后怎么办，让该干这事的模块自己去处理。
5.避免过度灵活
设计和代码并不是越灵活越好的。一个常见的例子是，使用泛型时可以使类或者方法操作不同的对象，然而，在 JAVA 常用的 三 层架构中，如果一系列的类本来就是针对某个特定实体的操作，就没有必要还指定为泛型，再在使用时指定为使用特定的实体类。这颇有画蛇添足的感觉。
6.减少锦上添花的功能
页面无刷新，更酷的显示效果等等，对于业务系统来说都是些锦上添花的事，如果因为这些而使业务界面非常复杂，给业务处理带来一系列的问题，极端情况是业务处理无法继续时，再漂亮的界面也是无用的。一个忠告时，仅在确保业务处理正确进行的前提下再考虑其他的。这一点有一个前提是与用户进行必要的沟通。也就是说，JAVA实现的项目，重点在于对业务的处理上，只有很好的实现了业务处理，才能去考虑界面的美观与用户的视觉感官 。
7.适当拆分
这一点与 4 类似。尽量降低每个模块的复杂度，让脑力劳动转化成体力劳动。一个常见的例子是，通常对某个表单都会有增加、修改、删除和查看的功能。但是，前三种操作通常仅在某个功能点上、特定状态和特定权限的人进行操作(也许仅在在系统中的唯一一个界面中)。而查看操作却会分布在项目的各个角落，如果将这四种操作都放在同一界面中，虽然可以减少界面数，但增加的却是这一界面的复杂度，要对各种状态、条件进行必须的判断来进行界面元素的只读设置，这个复杂度的增加是指数级的，而如果将查看拆分开，工作量将是线性的，就算要做10个查看界面，总比复杂度变成 10*10 要容易处理得多，况且还可以组件化。
8．与客户保持良好的沟通
很多人都没有注意去保持和客户的沟通，很多架构师都认为，只在项目的需求阶段才需要和客户有沟通和交流，这点是很不好的习惯，因为客户的要求会随着时间的变化而变化，只有经常和客户保持良好的沟通，才能在第一时间内了解客户的需求变化，从而调整自己的项目架构方案，在最短的时间满足客户的需求。
9．项目架构与数据库架构的联系
很多人都认为，项目在开发的过程中，是不需要数据库的，只要在内存中实现就可以了。我个人认为，这是一种很不好的开发习惯。数据库虽说是根据项目的具体需求而定。但一个项目在架构过程中完全不考虑数据库的架构，那很可能就会使项目中实现的东西，在数据库中很难记录或者是数据库设计很麻烦，无形中增加了项目开发的难度。并且，在项目的开发过程中不考虑数据库，可能会使项目在挂靠数据库后，出现部分业务逻辑的无法实现，数据的丢失等等问题。
当然，很多人的架构风格的不同，会有不同的架构见解，我的见解也不一定是正确的。希望大家可以从我的东西都学到一些东西，也希望大家可以多多交流在架构方面的看法