互联网公司或者是小型企业的公司，需要做一个可发展的技术平台，前期的发展需求就是快速的迭代技术产品，保证产品的更新及功能的升级。以扩展业务为主，不能考虑的太多，考虑基础技术架构的话，你就没有时间去实现变幻莫测的业务，也许你所在的企业没有来得及变化就已经退出历史舞台了。但是呢，在开始阶段也不能是随便的定义一个架构，前期的发展就是快速的实现业务功能，便于后期扩展，怎么样的技术架构可以快速开发又安全稳定呢？不要总是以现有业务为主，不要抱着后期推到重来的想法来想和做这件事。
技术选择：一定选择你熟悉的技术，不要一味的求高精尖的技术，前期就是快速的搭建技术架构，实现业务逻辑，所以一定要选择自己熟悉的技术，但是还有一点，结合当前技术团队的特点来选择对未来有发展的技术结构，考虑到后期可以平稳的过度。本身我是java出身，首先考虑的技术是spring架构，mybatis，mysql。上面选择的就可以实现很多功能技术，并且社区发展活跃，可以解决你碰到的几乎任何问题。
业务分层：业务分层一定要清晰，并且一定要按照既定的要求来完成业务操作，一般的业务分层是controller，service，dao三层模式来开发。不过需要注意一点的是：不管是否前后端分离，你都要考虑到前后端分离的结果，并且保证数据参数的安全，都要事先考虑一件事情，参数传入的问题，参数输出的问题，这两类参数是暴露给客户端的，一定要做中间转换，不能让使用客户端的人员猜测出我们的业务表结构。
controller层：要求该层只是做数据接受，业务调用，结果返回。并且考虑到spring的强大，你可以使用spring提供的RESTful风格来设计api。说到API，controller层是实现API设计的重要环节，模块设计要清晰，并且功能模块要区分明确。核心基础功能要单独开发，此时很多人都在使用的管理工具是maven，前期就可以考虑公用功能，抽象，接口等要单独开发，以jar包依赖的关系来管理。API的设计可以考虑到后期做功能扩展或者功能拆分的依据，可以逐步的拆分和扩展，保证原有功能的完整性，保证接受API层的controller的功能单一，不要把业务问题放在controller来完成，还有一个问题，每个系统都会和其他系统进行交互或者提供接口功能，抽闲的父类api设计要合理，保证两条不同的线路都可以走的通，并且做到数据的安全隔离。
service层：业务逻辑处理层，该层的核心内容就是业务逻辑处理，业务你的一个操作对controller层来说只是几个参数的问题，但是对业务逻辑来说可能是很复杂的，业务层是关系到功能的核心问题，所以前期的设计就很重要。业务接口，入参，出参三个设计要合理，并且针对功能的问题进行抽象化，保证代码的合理及重用，对于接口的命名，前期一定要设定好规范，不要每个人一套规范，还有就是返回值的问题，考虑到公用处理，建议使用枚举来设置返回状态。对于参数而言，一定不要出现null的值，除非是特定情况，保证每个参数都是默认值，确保程序的健壮性。在该业务层的操作还有一个大点就是业务拆分的痛点，也许马上面临读写分离，也许马上面临消息队里，更有面向缓存架构，这个都需要在前期考虑设计到，不要到最后在补充，面向互联网的应用都会面临的问题。所以就涉及到下面的问题，基础组件的功能，该功能组件一定要单独开发，达到公用的效果，即便是后期拆分和扩展，依旧可以重用。
dao层：该层和基础组件层是平行的，所以就同时讲了，该层实际上是比较简单的，做到单表单库的持久化操作，保证数据的隔离及安全，避免数据库安全问题就可以，一般都会采用mybatis的操作，适合互联网的orm操作，并且可以看到完整的sql构造，让开发是比较放心的。该层不错任何业务处理，只是简单的数据库操作，切记保证各层的分工明确，保证各层的功能单一。基础组件的设计更是考验一个人的能力，接口规范，技术组件的整合，接口规范可以体现在命名规则上一部分，你保存用户可以是insertUser，saveUser，你设计缓存的时候可以是cacheUser等结构，技术组件方面，一定要先设计好接口规范，并且实现一套公用的基础组件，但是不要设定要final的，确保每个单独系统有重写的功能，确保后续的系统有个性化需求来继承父类实现个性化基础组件或者新技术的整合。
上面写的是我的一些感悟，也许有不到之处，敬请指出，非常感谢！
扫一扫
211
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
