基于DotNet构件技术的企业级敏捷软件开发平台 AgileEAS.NET - 系统架构

简介:

   本文是继AgileEAS.NET应用开发平台介绍AgileEAS.NET之敏捷并行开发方法所做的架构补充,用于阐释AgileEAS.NET平台的架构设计思路。

      说起了系统架构,我也无法给出系统架构的确切定义,我的理解也许也只是基于自己经验的一个片断,我是学习园林专业身的,学习过园林建筑学,也许对软件框架最早的理解来源于对建筑的理解,我们知道,一个好的建筑必须解决建筑及其附属物的荷载及其美观和居住的舒适性,而这个必须通过其建筑的骨架--承重体系来支撑,建筑最先进行的其他承重休息的浇筑。

软件之系统架构有如建筑的骨架,不同规模、不同地域、不同应用的建筑会使用不同的承重结构。软件系统架构的设计如同对建筑的框架设计一样,对于不同的应用应该应用与之相匹配不同的架构,也就是说,客户的应用决定着项目的架构及到技术选项。

      AgileEAS.NET平台所提出的系统架构适应于中小规律的管理信息系统。

      在AgileEAS.NET应用开发平台介绍中我画出了AgileEAS.NET的基本架构图,本文我从系统的横向扩展和纵向伸缩两个方面来讨论。

横向扩展:

      AgileEAS.NET平台是基于“并行开发”这种思想支持的应用平台,我们在在DotNET中用平台+插件实现了这么一种理念,其核心的机制既用插件横行扩展平台。

      采用这种思路构建和扩展业务系统,需要一个统一的机制允许业务插件注册到平台,基于这种思路,各个业务模块,都变成了可以自由组装、拆卸的插件。

image

      插件运行容器是一组能够实现插件业务调用的一组应用程序,可以是基于WinFrom的桌面应用程序、也可以是基于Web的网站应用,运行容器调用插件并由插件横向扩展运行容器的功能,这样一来,应用系统的开发就转成为对运行容器的功能扩展,也就是项目的重点转移于开发模块插件这个焦点。

      业务插件的开发者可以选择利用AgileEAS.NET所提供的快速开发技术实现,即依赖于平台所提供的基础组件,也可以选用开发者自己的技术去实现模块插件,这将涉及到系统的纵向伸缩的问题。 

 

纵向伸缩:

 

      不要是说搞软件的技术人员,就是某些客户机构人员,也跟你嚷嚷的要求软件弄成三层结构才行,我想这个三并不指特定的三层吧,应该是泛指三或者多层结构吧。

      目前,大家所指的三层结构应该是对系统进行的所谓界面(UI)、业务逻辑(BI)、数据访问(DA)三层吧,多层也是对这三层进行了详细的分解的结果,业界经验证明,这确实是解决系统复杂性的一种主流模式。但并不是说应用了三层架构就一定能解决系统的复杂性,他不是万能的。他提供给我们一种解决复杂问题的思路,那就是根据应用的复杂程度合理的去分层。

image

      对于这种分层设计,我建议根据项目的实际情况合理的选择合理的分层设计,如果对于很小的项目选择复杂的分层设计,就会演变成为分层而分层的一种漩涡。

      AgileEAS.NET支持不同层级的开发,对于很简单的项目,你可以选择把界面、业务、数据访问全部放在模块模块UI实现;对于较复杂的项目,可以选择使用模块UI+数据访问层,把业务逻辑并入UI实现,更为复杂的项目可以把界面、业务、数据三部分严格分解甚至可以把这三层中的任务一层再分解,比方,数据访问层可以分解为数据访问接口层、数据访问实现层等,AgileEAS.NET提供一个基于消息的分布式通信服务,应用系统可选的基于它实现分布式应用。

      总之,系统的架构取决于客户的应用、技术力量等诸多方面,优秀的架构在于系统扩展、伸缩性以及系统的抽像程度之间寻找一种平衡。


作者:魏琼东 
出处:http://www.cnblogs.com/eastjade
关于作者:有13年的软件从业经历,专注于中小软件企业软件开发过程研究,通过在技术与管理帮助中小软件企业实现技术层面开源节流的目的。熟悉需求分析、企业架构、项目管理。现主要从事基于AgileEAS.NET平台的技术咨询工作,主要服务于医疗卫生、铁路、电信、物流、物联网、制造、零售等行业。如有问题或建议,请多多赐教! 
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,如有问题,可以通过mail.james@qq.com 联系我,也可以加入QQ群:113723486、199463175、116773358、116773358、212867943、147168308、59827496、193486983、15118502和大家共同讨论,非常感谢。


    本文转自魏琼东博客园博客,原文链接:http://www.cnblogs.com/eastjade/archive/2010/04/20/1715806.html,如需转载请自行联系原作者

相关文章
|
3月前
|
数据采集 运维 监控
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
|
6月前
|
消息中间件 运维 监控
企业级短信验证码服务架构设计与最佳实践
随着移动互联网的发展,短信验证码成为用户身份验证的重要手段。本文从企业级应用角度出发,探讨如何构建高可用、高并发和安全可靠的短信验证码服务。通过多通道冗余、故障自动切换和服务降级保障高可用性;利用异步处理与消息队列应对高并发;借助多层防刷、内容审核和数据加密提升安全性。同时,提供了详细的架构设计、核心模块代码示例以及监控运维方案,帮助读者理解并实现一个完整的短信验证码系统。
316 2
|
6月前
|
存储 SQL 分布式计算
19章构建企业级大数据平台:从架构设计到数据治理的完整链路
开源社区: 贡献者路径:从提交Issue到成为Committer 会议演讲:通过DataWorks Summit提升影响力 标准制定: 白皮书撰写:通过DAMA数据治理框架认证 专利布局:通过架构设计专利构建技术壁垒
|
10月前
|
存储 算法 安全
.NET 平台 SM2 国密算法 License 证书生成深度解析
授权证书文件的后缀通常取决于其编码格式和具体用途。本文档通过一个示例程序展示了如何在 .NET 平台上使用国密 SM2 算法生成和验证许可证(License)文件。该示例不仅详细演示了 SM2 国密算法的实际应用场景,还提供了关于如何高效处理大规模许可证文件生成任务的技术参考。通过对不同并发策略的性能测试,开发者可以更好地理解如何优化许可证生成流程,以满足高并发和大数据量的需求。 希望这段描述更清晰地传达了程序的功能和技术亮点。
1123 14
.NET 平台 SM2 国密算法 License 证书生成深度解析
|
3月前
|
存储 消息中间件 安全
企业级实时消息推送系统的架构设计,一文即懂!
如果你是技术负责人,该如何搭建一套能解决这些问题的企业级统一消息推送平台?今天我们就从核心挑战出发,拆解一套可落地的统一推送服务架构方案。
420 0
|
5月前
|
人工智能 监控 数据可视化
企业级LLMOps落地指南:蜂巢架构×可视化编排实战
本文将基础的单应用扩展成多应用,并实现工作流组件,包括:多应用模块设计、工作流模块设计、LangGraph实现图应用、前端Vue-Flow组件使用、工作流转LLM工具设计思路、关联工作流登技巧。
280 3
企业级LLMOps落地指南:蜂巢架构×可视化编排实战
|
5月前
|
消息中间件 人工智能 安全
企业级AI应用需要系统工程支撑,如何通过MCP大模型架构实现全链路实战解构?
本文三桥君深入探讨了MCP大模型架构在企业级AI应用中的全链路实战解构。从事件驱动、统一中台、多端接入、API网关、AI Agent核心引擎等九个核心模块出发,系统阐述了该架构如何实现低耦合高弹性的智能系统构建。AI专家三桥君提出从技术、内容、业务三个维度构建评估体系,为企业级AI应用提供了从架构设计到落地优化的完整解决方案。
286 0
|
8月前
|
缓存 监控 安全
301重定向进阶指南:从基础配置到企业级架构优化
本文深入探讨网站重定向的高级技巧与企业级实现,涵盖正则表达式重定向、权重无损迁移、分布式系统适配等核心内容。通过解析301/302状态码区别及应用场景,结合Nginx、Apache配置示例,帮助开发者优化大规模网站重定向逻辑。同时,文章介绍CDN边缘重定向、微服务架构下的规则管理以及容灾设计,确保高性能与安全性。最后提供全链路监控方案和经典案例分析,助你规避流量损失风险,提升SEO表现。
304 38
|
8月前
|
监控 应用服务中间件 区块链
301重定向的终极指南:从基础配置到企业级架构设计
本文全面解析301重定向技术,从基础配置到企业级架构设计。涵盖HTTP状态码语义、浏览器与爬虫处理差异,提供分层架构模型及高可用配置示例。深入探讨亿级URL处理策略、流量压力测试数据,结合HTTP/2优化与Core Web Vitals提升方案。同时关注隐私合规性、故障排查工具及前沿技术融合,如机器学习预测和区块链存证。最后通过实际案例分析,展示重定向工程的商业价值与未来趋势。
223 14
|
8月前
|
人工智能 自然语言处理 物联网
如何成为企业级大模型架构师?
企业级大模型架构师需要掌握从 底层算力、模型训练、微调优化、推理部署、企业集成 到 安全合规 的全栈能力。这里提供一个完整的 企业级大模型架构师成长体系。
842 4

热门文章

最新文章