认识达内从这里开始

软件编程开发架构技术是大多数java编程开发程序员都应该熟练掌握的一个编程开发技术，而本文我们就通过案例分析来简单了解一下，软件开发应用架构设计注意事项分析。

应用架构设计简单

应用本身是有架构分层的，合理的系统分层应该包括表现层，领域逻辑层，数据源层。表现层主要提供服务，处理用户请求。领域层是处理逻辑，是系统的核心。数据源层与数据层、消息系统，与其他软件包通信。

后续发展的领域驱动架构设计，演变成四层，在表现层下加入了应用层，同时把数据源层改为基础设施层，突破了数据库管理系统的限制。

基于以上的系统分层，无论你是采用的三层架构还是四层架构，应用代表着功能边界，提供那些核心的能力，能做那些事情，那些事情不能做。

一个好的实践经验是参考领域驱动设计的业务域的方法论，梳理好系统的一二三级域，多不超过四级，做好各级域的定义。好的域的定义代表着系统能力的边界，让你明白那些事情能做，那些事情不能做。

基于以上梳理好的系统业务域的定义和能力边界，我们在梳理的时候通常会两类系统，一类是现有存量的系统且需求迭代相对频繁的系统，这类系统关键是要梳理出有哪些核心的能力，是否在上述系统的域的定义范围内的，是否其他系统有类似的能力，如果有的话，需要考虑合并。另外还需要考虑核心能力公开化、文档化，至少让部门内知道，有地可查，避免系统的重复造轮子。

遇到二类系统是存量系统且没有需求迭代，业务上基本没有调用量的。这类系统需要和业务沟通是否有下线计划，是否有类似的系统可以替代，给业务决策提供技术参考。

应用拆分合理

需求开发中，一个项目或者需求的实现可能需要多个目标系统协同来实现，这涉及到目标系统的拆分的粒度，系统拆分成应用的粒度没有统一标准，但是要在相对合理范围内，可以参考的因素包括业务规划，系统调用量级，基于业务规划的架构设计，部门内的人数及分工。过多过少都是不好的。

如果一个新业务短期内看不到大的发展，在初步规划应用的时候，可以先粗粒度拆分，部门内人数平均不能应该超过2-3个应用，再多必然面临着一个需求实现的时候不同系统的切换成本。如果后续业务发展起来，部门内人数增多，因为分工更精细，可以考虑更细粒度的拆分，系统拆分必然会带来另一个问题，系统之间该如何的协同以及系统的调用链路的长度。

基于以上讲的系统分层的概念，部门内系统可以分为两类，一类系统是业务网关，一类是通用的业务能力。业务网关面向用户，用来协同应用的活动，不包含业务逻辑，不保留业务对象的状态，相当于领域驱动设计应用层+表现层，有人称作它为业务SOA，或者BFF层。

通用业务能力相当于领域逻辑层+基础设施层，作为软件的核心所在，保留了业务对象的状态，对业务对象的持久化被委托给基础设施层，基础设施层作为其他层的支撑层，实现了和其他系统的通信，实现业务对象的持久化。

在以上两类系统中，业务网关是依赖通用业务能力层，业务网关是北向依赖，通用业务能力层是南向依赖。在一个功能的实现不建议链路长度不超过2。同时也要注意到系统之间相互依赖的情况，要重视，此点是系统稳定性的风险点。

成本量化：

基于以上三方面分析，梳理出的交付物:1、系统的上下文依赖;2、系统的业务域定义及能力规划地图。3、应用调用链路的长度及相互的依赖关系;4、应用拆分粒度合理性的评估;5、系统中能力的下沉或者合并;6、业务量少的系统列表。

其中1-4，可以看作系统的行动指南或者原则，5-6是下一步的行动，更简单的说是我们常做的系统的关停并转。在业务部门系统关停并转还需要考虑到成本问题，做好成本的量化。

先需要评估关停并转的付出的成本，其次要评估系统日常维护1-3年的成本包括人力成本和机器资源的成本，前者和后者的三年累计值相减，如果大于零，系统建议暂时不动，如果少于零，可以考虑关停并转的计划。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。