课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
如果大家学习过java编程开发语言的话应该知道,java编程开发语言在企业级应用开发领域使用是非常频繁的,下面我们就一起来了解一下,关于企业级架构设计中的一些调整方法。
原有架构设计中的疏漏。这一点是架构师们不愿意看到,出现疏漏证明了原有工作的缺失,不过,“知漏就改还是好同志”,别给自己找什么借口,坦然承认,补充设计,调整架构方案,越是虚怀若谷,越是赢得尊重。项目都是有周期的,每个环节都必须有一定的时限,除了次做企业级转型之外,业务架构设计是非常重要却又不能被分配太多时间的环节,想想对项目的“敏捷”要求,如果让业务架构师自己慢条斯理地搞起细致的业务架构设计,相信所有人都会疯掉。那么,业务架构师就必须在尽可能短的时间内给出覆盖度尽可能完整的架构方案,这是对业务架构师的考验。但是,平心而论,时间越短、信息越少,就越可能出现疏漏,在细化阶段发现问题就很正常,自然调整就好,各方都不必苛求。
出现了更好的设计。上一讲的虚拟案例中就提供了改良的可能性,“检查客户信息”这个任务独立出来,可能会给整个企业级设计带来一定的改善,方便其他业务领域实现同类需求,这样的改良就可以回补到模型中,由此带来的架构调整是有益的。
对现实妥协的等价方案。架构设计经常不是只有一个可行方案,人们常说,架构师就是在手里永远准备两套方案,并随时准备抛弃其中一套。我个人也经历过这样的事情,原本设计时有两个方案可以选择,在为C领域做业务架构设计时,A领域和B领域都有可以采用的会计引擎实现能力,A领域的业务性质与C领域更为接近,于是做架构设计时选择了A领域,但是实际推进项目时,负责A领域的项目组由于客观条件限制,无法按时实现,只好再转到B领域,两个方案基本等价,但是架构和模型上必须要做一定的调整,这是现实条件制约的。对了,不要问我为什么两个领域都会有类似的会计引擎实现能力,这是另一种现实。
架构设计错误。与一点不同,这是实实在在的错误,是架构师们一直竭力避免的情况,这对架构设计和架构师自身能力的可靠性都是直接的挑战,对此,架构师应当做的就不仅是调整了,更重要的是深入了解错误原因,总结经验,反省和提升自我,由此,也看出经验在架构师综合素质中的重要性,好的架构师都是时间和项目铸就的。但是,如果一个架构师经常出现此类问题,就必须考虑对其进行调整了,或是到项目组重新锻炼,或是不再让其担任架构职责。如果是整个架构师团队经常出现此类问题,那就很可能是工作机制的原因,是不是架构师没有机会深入参与到项目过程中去了解项目实际情况?是不是上一讲提到的“违章建筑”太多,导致架构已经失灵?总之,集体问题与个体问题不同,需要区别对待。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。